sortie-dogs 0.11.3 → 0.11.4

package/dist/asset-version.d.ts

@@ -4,5 +4,5 @@
  */
 export declare const RUNTIME_ASSET_VERSION = "0.3.89-completion-proof-v1";
 export declare const V010_RUNTIME_ASSET_VERSION = "0.10.0-v0912-language4-cost-rpt10-compaction-ref2-proposal1-review-remediation1-surface4-proposal-recovery2-quality1-terminal2-route1-path1-permission2-prerequisite1-v2-bridge1-intent1-reflection1-cancel1-proposal-budget1-goal-recovery1-delegate-execute1-v2-depth1-process-replacement1-unstarted-v2-1-cold-turn1-return-report-v2-2-root-revision1";
-export declare const V011_RUNTIME_ASSET_VERSION = "0.11.3-cooperative-progress-v1";
+export declare const V011_RUNTIME_ASSET_VERSION = "0.11.4-soft-pacing-v1";
 export type RuntimeAssetVersion = typeof RUNTIME_ASSET_VERSION | typeof V010_RUNTIME_ASSET_VERSION | typeof V011_RUNTIME_ASSET_VERSION;

package/dist/asset-version.js

@@ -4,4 +4,4 @@
  */
 export const RUNTIME_ASSET_VERSION = "0.3.89-completion-proof-v1";
 export const V010_RUNTIME_ASSET_VERSION = "0.10.0-v0912-language4-cost-rpt10-compaction-ref2-proposal1-review-remediation1-surface4-proposal-recovery2-quality1-terminal2-route1-path1-permission2-prerequisite1-v2-bridge1-intent1-reflection1-cancel1-proposal-budget1-goal-recovery1-delegate-execute1-v2-depth1-process-replacement1-unstarted-v2-1-cold-turn1-return-report-v2-2-root-revision1";
-export const V011_RUNTIME_ASSET_VERSION = "0.11.3-cooperative-progress-v1";
+export const V011_RUNTIME_ASSET_VERSION = "0.11.4-soft-pacing-v1";

package/dist/core/work-loop.d.ts

@@ -224,6 +224,9 @@ export declare class WorkLoop {
         status: string;
         exit: number | null;
     }): Promise<void>;
+    /** Record a non-interrupting pacing nudge for the running child. The phase, child and conversation are unchanged. */
+    nudge(root: string, callID: string, reason: string, limit: number): Promise<boolean>;
+    /** Legacy v0.11.0-v0.11.3 hard yield. Retained for persisted states; the v0.11.4 plugin no longer calls it. */
     stall(root: string, callID: string, reason: string): Promise<boolean>;
     beginCommand(root: string, callID: string, command: string, timeout: number, retryOf?: string): Promise<{
         command: WorkCommand;

package/dist/core/work-loop.js

@@ -465,7 +465,7 @@ export class WorkLoop {
                 "## Original user instructions (all remain authoritative)", ...work.requests.map(item => item.text),
                 "## Operator notes", work.instructions, ...work.feedback,
                 "Use native read/glob/grep/patch/shell tools freely within the user's instructions and project AGENTS.md. Discover dependencies and affected files as you work.",
-                "Act early: reuse supplied paths and existing documented commands. Investigate only the next unknown that prevents a target reproduction, then act on the result. Do not recreate a controller or repeat known preflight. Shell, patch and checks do not reset the host's receipt-time clock. A planning stall returns internally for same-child correction, not user intervention. Running commands retain native deadlines; activity does not prove completion.",
+                "Act early: reuse supplied paths and existing documented commands. Investigate only the next unknown that prevents a target reproduction, then act on the result. Do not recreate a controller or repeat known preflight. Keep going until the whole task is finished in this invocation; the host never cuts you off for pacing, it only adds a short note if you stop editing or executing. Running commands retain native deadlines; activity does not prove completion.",
                 ...(work.commands?.length ? ["## Already executed by the host — reuse these results, never blindly relaunch", JSON.stringify(work.commands)] : []),
                 "Run final meaningful checks with sortie_v011_check. Each remains an obligation until it passes on final source; use shell for exploration. Fix ordinary setup and test failures in this invocation. Verify the actual affected behavior and adjacent valid/invalid cases, not just syntax or one literal reproducer.",
                 "Return a concise account of changes, check IDs, requirements covered and anything genuinely unresolved. Never accept your own work or ask the user to fix a protocol field."].join("\n\n");
@@ -497,6 +497,12 @@ export class WorkLoop {
                 // Activity is visible liveness, not reviewed progress or accepted work.
                 // Keep the original request and review clocks unchanged.
                 progress.lastActionAt = Date.now();
+                // A finished edit or executed command restarts the nudge window. This is
+                // pacing only; it still certifies neither progress nor completion.
+                if (isWorkAction(active.tool)) {
+                    progress.reviewedAt = progress.lastWorkActionAt = Date.now();
+                    progress.reviewedTools = progress.tools;
+                }
                 if (result.status === "completed" && activity.tool === "patch")
                     progress.edits++;
                 if (result.status === "completed" && result.exit !== null && activity.tool === "shell")
@@ -508,6 +514,7 @@ export class WorkLoop {
                 progress.active.push({ ...activity, actor: child });
                 progress.tools++;
                 if (isWorkAction(activity.tool)) {
+                    progress.firstActionAt ??= Date.now();
                     if (activity.tool !== "patch")
                         progress.commands++;
                 }
@@ -516,6 +523,25 @@ export class WorkLoop {
             }
         });
     }
+    /** Record a non-interrupting pacing nudge for the running child. The phase, child and conversation are unchanged. */
+    async nudge(root, callID, reason, limit) {
+        return this.update(root, async (state) => {
+            const work = state.work;
+            if (!work || work.phase !== "running" || work.callID !== callID)
+                return false;
+            const progress = work.progress ??= newWorkProgress(work.startedAt);
+            const nudges = progress.nudges ??= [];
+            if (nudges.filter(item => item.at > (progress.lastWorkActionAt ?? 0)).length >= limit)
+                return false;
+            nudges.push({ at: Date.now(), reason });
+            if (nudges.length > 64)
+                nudges.shift();
+            progress.reviewedAt = Date.now();
+            progress.reviewedTools = progress.tools;
+            return true;
+        });
+    }
+    /** Legacy v0.11.0-v0.11.3 hard yield. Retained for persisted states; the v0.11.4 plugin no longer calls it. */
     async stall(root, callID, reason) {
         return this.update(root, async (state) => {
             const work = state.work;

package/dist/core/work-progress.d.ts

@@ -43,22 +43,37 @@ export interface WorkProgress {
     operatorNudgedAt?: number;
     evidence?: WorkEvidence[];
     interventions?: WorkIntervention[];
+    firstActionAt?: number;
+    lastWorkActionAt?: number;
+    nudges?: {
+        at: number;
+        reason: string;
+    }[];
 }
+/** Pacing only nudges. It never interrupts a model response or returns the child to the operator. */
 export declare const WORK_PROGRESS_LIMITS: {
     readonly idleMs: 60000;
     readonly operatorMs: 30000;
     readonly inspections: 12;
     readonly intervalMs: 1000;
+    readonly nudgesPerWindow: 2;
 };
 export declare const isWorkAction: (tool: string) => boolean;
 export declare function newWorkProgress(now?: number): WorkProgress;
 export declare function progressLimit(progress: WorkProgress, now: number, idleMs: number, inspections: number): string | null;
+/** Reasoning-free measurements of the pain this pacing targets. */
+export declare function pacingMetrics(progress: WorkProgress): {
+    first_action_ms: number | null;
+    nudges: number;
+};
 export declare function progressView(progress: WorkProgress, now?: number): {
-    phase: string;
     elapsed_ms: number;
     idle_ms: number;
     summary: string;
     note: string;
+    first_action_ms: number | null;
+    nudges: number;
+    phase: string;
     startedAt: number;
     lastActionAt: number;
     inspections: number;
@@ -80,6 +95,8 @@ export declare function progressView(progress: WorkProgress, now?: number): {
     operatorNudgedAt?: number;
     evidence?: WorkEvidence[];
     interventions?: WorkIntervention[];
+    firstActionAt?: number;
+    lastWorkActionAt?: number;
 };
 type RecordValue = Record<string, any>;
 /** Repair only the outgoing context, including the trailing interrupted turn that native normalization misses.

package/dist/core/work-progress.js

@@ -1,4 +1,5 @@
-export const WORK_PROGRESS_LIMITS = { idleMs: 60_000, operatorMs: 30_000, inspections: 12, intervalMs: 1_000 };
+/** Pacing only nudges. It never interrupts a model response or returns the child to the operator. */
+export const WORK_PROGRESS_LIMITS = { idleMs: 60_000, operatorMs: 30_000, inspections: 12, intervalMs: 1_000, nudgesPerWindow: 2 };
 export const isWorkAction = (tool) => ["shell", "patch", "sortie_v011_check"].includes(tool);
 export function newWorkProgress(now = Date.now()) {
     return { startedAt: now, lastActionAt: now, inspections: 0, tools: 0, commands: 0, edits: 0, active: [],
@@ -12,15 +13,20 @@ export function progressLimit(progress, now, idleMs, inspections) {
         return null;
     const calls = progress.tools - (progress.reviewedTools ?? 0);
     if (calls >= inspections)
-        return `discovery-limit: ${calls} calls without operator-confirmed relevant evidence`;
+        return `discovery-limit: ${calls} calls without an edit or executed command`;
     if (now - (progress.reviewedAt ?? progress.startedAt) >= idleMs)
-        return `planning-timeout: no operator-confirmed result for ${Math.floor((now - (progress.reviewedAt ?? progress.startedAt)) / 1000)}s`;
+        return `planning-timeout: no edit or executed command for ${Math.floor((now - (progress.reviewedAt ?? progress.startedAt)) / 1000)}s`;
     return null;
 }
+/** Reasoning-free measurements of the pain this pacing targets. */
+export function pacingMetrics(progress) {
+    return { first_action_ms: progress.firstActionAt === undefined ? null : Math.max(0, progress.firstActionAt - progress.startedAt),
+        nudges: progress.nudges?.length ?? 0 };
+}
 export function progressView(progress, now = Date.now()) {
     const active = progress.active.at(-1);
     const phase = progress.stopped ? "correcting" : active ? isWorkAction(active.tool) ? "executing" : "inspecting" : "thinking";
-    return { ...progress, phase, elapsed_ms: Math.max(0, now - progress.startedAt),
+    return { ...progress, phase, ...pacingMetrics(progress), elapsed_ms: Math.max(0, now - progress.startedAt),
         idle_ms: Math.max(0, now - progress.lastActionAt),
         summary: progress.stopped?.reason ?? (active ? `${active.tool}: ${active.detail}` :
             progress.last ? `Last ${progress.last.tool}: ${progress.last.status}${progress.last.exit === null ? "" : ` (exit ${progress.last.exit})`}; awaiting next action` : "Waiting for first executable step"),

package/dist/plugin/work-loop-v2.js

@@ -43,12 +43,10 @@ export function createUserProxyPlugin() {
             const stopping = new Map();
             const lifetime = new AbortController();
             const thinking = new Map(), nudging = new Set(), stoppedByUser = new Set();
-            const internalStops = new Set();
             const controllerRoots = new Set();
             let observingControllers = false;
             const nativeCommands = new Map();
-            const childTurns = new Map();
-            const inFlightRequests = new Set(), localYields = new Set();
+            const inFlightRequests = new Set();
             const launchPermissions = new Map();
             await context.permission.hook("evaluate", async (event) => {
                 // Observe the native permission decision without changing it. Keeping the
@@ -375,22 +373,12 @@ export function createUserProxyPlugin() {
                         if (attempt > loop.maxAttempts)
                             return;
                         const noticeID = `msg_${createHash("sha256").update(`${id}/${progress.startedAt}/${attempt}`).digest("hex").slice(0, 24)}`;
-                        try {
-                            await context.session.synthetic({ sessionID: id, id: noticeID, resume: false, delivery: "steer",
-                                description: "🐾 Sortie: execution pacing correction",
-                                metadata: { "sortie-dogs/pacing": true, receivedAt: progress.startedAt, attempt },
-                                text: "Host pacing intervention: the current operator response has not reached its next action. Preserve the original user request. For an action request use start_work now with any known command, or dispatch its existing task. At review, inspect the actual result and decide. Answer a question directly. This is host control, not a new user request. Do not repeat reconnaissance or ask the user to hurry routine work." });
-                            if (!stoppedByUser.has(id) && !lifetime.signal.aborted) {
-                                internalStops.add(id);
-                                const interrupted = await context.session.interrupt({ sessionID: id, resume: true });
-                                if (isRecord(interrupted) && interrupted.interrupted === false)
-                                    internalStops.delete(id);
-                            }
-                        }
-                        catch (error) {
-                            internalStops.delete(id);
-                            throw error;
-                        }
+                        // Steer at the next step boundary. Interrupting here restarted the operator's
+                        // reasoning from scratch, which lengthened exactly the delay it targeted.
+                        await context.session.synthetic({ sessionID: id, id: noticeID, resume: false, delivery: "steer",
+                            description: "🐾 Sortie: execution pacing note",
+                            metadata: { "sortie-dogs/pacing": true, receivedAt: progress.startedAt, attempt },
+                            text: "Host pacing note: preserve the original user request. For an action request call start_work now with any known command, or dispatch its existing task. At review, inspect the actual result and decide. Answer a question directly. This is host control, not a new user request. Do not repeat reconnaissance." });
                     })().catch(error => console.warn("[sortie-dogs-v011] operator pacing", error)).finally(() => {
                         if (!deferred && thinking.get(id) === since)
                             thinking.delete(id);
@@ -424,26 +412,12 @@ export function createUserProxyPlugin() {
                             const current = await loop.current(id);
                             if (!current || current.id !== work.id || current.callID !== work.callID || !current.progress)
                                 return;
+                            // Display only. The child's reasoning and context are never discarded by a
+                            // host clock; pacing is a note at its next request boundary.
                             const progress = progressView(current.progress);
                             await report({ ...metadata, ...(current.child ? { sessionID: current.child } : {}),
-                                description: `🐾 ${progress.phase} · ${Math.floor(progress.elapsed_ms / 1000)}s · ${progress.summary}`,
+                                description: `🐾 ${progress.phase} · ${Math.floor(progress.elapsed_ms / 1000)}s · ${progress.summary}${progress.nudges ? ` · 促し${progress.nudges}` : ""}`,
                                 sortie_progress: progress });
-                            const reason = current.phase === "running" ? progressLimit(current.progress, Date.now(), planningMs, discoveryCalls) : null;
-                            // The provider owns an in-flight response's timeout. The review clock
-                            // must not discard its reasoning every minute. Review at the next
-                            // request boundary; retain the timer only for a stalled native handoff.
-                            const turn = current.child ? childTurns.get(current.child) : undefined;
-                            const deadline = Math.max(current.progress.nextInterventionAt ?? 0, (current.progress.reviewedAt ?? current.progress.startedAt) + planningMs);
-                            const grace = Math.min(10_000, planningMs / 4);
-                            if (reason && !inFlightRequests.has(current.child ?? "") && !current.progress.active.length &&
-                                Date.now() - current.progress.lastActionAt >= planningMs &&
-                                (turn === undefined || Date.now() >= deadline + grace || Date.now() - turn >= planningMs) && await loop.stall(id, work.callID, reason)) {
-                                // Yield is internal; the real foreground return wakes the operator after child settlement.
-                                if (current.child)
-                                    await context.session.interrupt({ sessionID: current.child, resume: false });
-                                await report({ ...metadata, ...(current.child ? { sessionID: current.child } : {}),
-                                    description: `🐾 軌道修正 · ${reason}`, sortie_progress: progressView((await loop.current(id)).progress) });
-                            }
                         };
                         const tick = () => {
                             if (ended || pending || lifetime.signal.aborted)
@@ -462,31 +436,13 @@ export function createUserProxyPlugin() {
                             return { ...result, metadata: { ...metadata, ...(isRecord(result.metadata) ? result.metadata : {}),
                                     sortie_progress: (await loop.current(id))?.progress ? progressView((await loop.current(id)).progress) : null } };
                         }
-                        catch (error) {
-                            const current = await loop.current(id);
-                            if (!localYields.has(work.callID) || current?.phase !== "yielded" || !current.child || current.callID !== work.callID ||
-                                current.userStopped || stoppedByUser.has(id) || execution.signal?.aborted)
-                                throw error;
-                            // Only our unsent-request checkpoint is a normal control return.
-                            // Native failures, user cancellation and failed checks stay failures.
-                            const checkpoint = JSON.stringify({ status: "checkpoint", work_id: current.id,
-                                reason: current.progress?.stopped?.reason, accepted: false,
-                                next: "Inspect work_status and the actual results, then continue the same child with a concrete correction or review completed scope. This checkpoint is not task completion." });
-                            return { output: { sessionID: current.child, status: "completed", output: checkpoint },
-                                content: [{ type: "text", text: checkpoint }],
-                                metadata: { ...metadata, status: "completed", sessionID: current.child, sortie_checkpoint: true,
-                                    description: "🐾 進捗確認 — 同じ作業を継続", sortie_progress: current.progress ? progressView(current.progress) : null } };
-                        }
                         finally {
                             ended = true;
                             clearInterval(timer);
                             monitors.delete(timer);
-                            localYields.delete(work.callID);
                             const current = await loop.current(id);
-                            if (current?.child) {
-                                childTurns.delete(current.child);
+                            if (current?.child)
                                 inFlightRequests.delete(current.child);
-                            }
                             await pending;
                         }
                     };
@@ -680,7 +636,6 @@ export function createUserProxyPlugin() {
                 if (id === owner)
                     thinking.delete(id);
                 if (session.agent === worker) {
-                    childTurns.delete(id);
                     await loop.assertWorker(owner, id);
                     if (event.tool === "subagent")
                         throw new Error("work-worker-does-not-delegate");
@@ -731,16 +686,15 @@ export function createUserProxyPlugin() {
                 const owner = await root(String(event.sessionID)), work = await loop.current(owner);
                 if (event.kind !== "auxiliary")
                     inFlightRequests.delete(String(event.sessionID));
+                let pacingNote;
                 if (session.agent === worker && event.kind !== "auxiliary" && work?.phase === "running" && work.callID && work.progress) {
                     const reason = progressLimit(work.progress, Date.now(), planningMs, discoveryCalls);
-                    if (reason && await loop.stall(owner, work.callID, reason)) {
-                        // No provider request has been sent for this step. The native failed
-                        // return wakes the operator; it reconciles and continues the SAME child.
-                        childTurns.delete(String(event.sessionID));
-                        localYields.add(work.callID);
-                        throw new Error(`work-pacing-yield-before-request: ${reason}`);
-                    }
-                    childTurns.set(String(event.sessionID), Date.now());
+                    // Never interrupt or return the child: that discarded its context and made the
+                    // operator redispatch the same investigation. Nudge within this same request.
+                    if (reason && await loop.nudge(owner, work.callID, reason, WORK_PROGRESS_LIMITS.nudgesPerWindow))
+                        pacingNote =
+                            `Host pacing note (${reason}). This is not an error and nothing was interrupted. Stop surveying: make your next tool call ` +
+                                "an edit (patch) or run the target reproduction/test (shell or sortie_v011_check). If a real blocker prevents that, report it now.";
                 }
                 if (session.agent === primary && event.kind !== "auxiliary" && !stoppedByUser.has(owner)) {
                     const progress = await loop.progress(owner);
@@ -756,11 +710,14 @@ export function createUserProxyPlugin() {
                 }
                 if (Array.isArray(event.system) && work)
                     event.system.push({ type: "text", text: `SORTIE v0.11 durable work ${work.id}; phase=${work.phase}. User intent survives compaction. ` +
-                            (session.agent === primary ? "Your role is the user's proxy: delegate routine work, compare results with every original instruction, and accept only with review_work. " : "You own all routine investigation, edits, testing and corrections. ") +
+                            (session.agent === primary ? "Your role is the user's proxy: delegate routine work, compare results with every original instruction, and accept only with review_work. " +
+                                "Dispatch a ready task immediately and let the child run to completion; do not investigate in parallel or re-read raw tool-output files. " : "You own all routine investigation, edits, testing and corrections. ") +
                             "Use work_status after compaction for current evidence. Do not reconstruct a proposal or an execution manifest." });
                 if (session.agent === worker && work?.progress && Array.isArray(event.system)) {
-                    event.system.push({ type: "text", text: `Execution pacing: ${work.progress.tools} cumulative parent/child calls; received ${Math.floor((Date.now() - work.startedAt) / 1000)}s ago. Unreviewed planning limit ${planningMs / 1000}s. ` +
-                            "Reuse supplied paths and documented commands. Run the relevant reproduction or existing controller early. For long work, use the native shell/controller and its existing ledger; do not repeatedly poll or invent a replacement runner. If blocked, return the exact blocker promptly." });
+                    event.system.push({ type: "text", text: "Execution pacing: act first. Reuse supplied paths and documented commands; run the relevant reproduction or existing controller early and interleave short inspection with edits. " +
+                            "For long work, use the native shell/controller and its existing ledger; do not repeatedly poll or invent a replacement runner. If blocked, return the exact blocker promptly." });
+                    if (pacingNote)
+                        event.system.push({ type: "text", text: pacingNote });
                 }
                 if (session.agent === worker && work && Array.isArray(event.system) && work.requests.length > (work.deliveredRequests ?? 0)) {
                     event.system.push({ type: "text", text: "Additional original user instructions received during execution:\n" +
@@ -964,8 +921,6 @@ export function createUserProxyPlugin() {
                     if (!["session.execution.interrupted", "session.execution.failed"].includes(String(event.type)))
                         continue;
                     inFlightRequests.delete(id);
-                    if (internalStops.delete(id))
-                        continue;
                     try {
                         const session = await info(id);
                         if (session.agent === primary && !session.parentID)

package/dist/runtime-assets-v011.d.ts

@@ -1,4 +1,4 @@
 import type { RuntimeAsset } from "./runtime-assets.js";
-export declare const OPERATOR_INSTRUCTIONS = "# Sortie-dogs v0.11 \u2014 the user's proxy\n\nYou are the only user-facing operator. Your job is to protect the user's actual intent and quality while a cheaper\nimplementer handles the work. Use the user's language. Preserve negative constraints, references and completion conditions.\n\nFor an action request:\n1. Announce \uD83D\uDE80 \u51FA\u6483 and the immediate action in at most three lines. Call sortie_v011_start_work as your first action tool.\n   If a command/runner and its inputs are already known, supply command to execute it immediately inside this call.\n   Use the original authority and scope; no extra child turn is needed just to decide how to launch a known command.\n   For a fix or feature, a test command already supplied by AGENTS.md or the user is a useful immediate reproduction:\n   run it with command before delegating diagnosis. A failed real reproduction is useful evidence, not an external blocker.\n    When ordinary investigation or implementation is needed, add only short useful guidance.\n    The immediate command is for known execution/reproduction/verification, not inline source edits that bypass the cheap implementer.\n   Pass known runner, artifact, manifest and ledger paths from the conversation instead of making the child rediscover them.\n   The host retains the original request automatically. Reuse execution_results; do not relaunch an existing command.\n   Dispatch the returned task through subagent verbatim, foreground, when implementation/diagnosis remains.\n   For a completed direct command, run the required check and review the actual result yourself.\n2. Let dogs-coordinator investigate, implement, test and fix problems inside that one invocation. It has native search,\n   editing and shell tools. Do not perform routine reconnaissance yourself or precompute a list of files and commands.\n3. After the child returns, call sortie_v011_work_status. Inspect the actual changed source/diff and validation receipts.\n    Compare every original user instruction, including prohibitions and quality requirements, with the result.\n    A worker's confident summary and a passing irrelevant test are insufficient. Read any relevant source the packet omits.\n    Inspect stored check output with work_status(check_ids=[...]), especially failed/blocked checks and claimed behavior tests.\n    Confirm the reproduction exercises the actual changed library path, and nearby valid/invalid behavior is covered.\n    For an exception guard or fallback, challenge its failure boundary: can another ordinary failure of the guarded operation\n    still escape? Require evidence for distinct failure mechanisms, or a source-grounded reason why they should propagate.\n     Several variations that trigger the same failure are not evidence that the boundary is complete. Delegate missing probes.\n     If the fix changes a shared type/format dispatch or membership list, compare its supported family with the local\n     registry/converters/consumers. Require coverage for other members with the same semantics, or a source-grounded reason\n     to exclude them. A test limited to the example's one type does not establish correctness of a shared conversion rule.\n     Verification chosen for acceptance remains required after an interrupted or rejected tool call. Repair its setup and\n     rerun the same coverage; do not relabel it exploratory merely because a recovery command used shell or start_work.\n4. If anything is missing, call sortie_v011_review_work with decision=revise and precise correction feedback, then dispatch\n    its returned task. This resumes the same cheap child. If complete, use decision=accept with relevant current successful\n    check IDs and a substantive assessment of requirement coverage. Only its succeeded receipt means accepted completion.\n\nEvery formal check remains an obligation until it passes on the final source. Source edits and unrelated passing checks\ndo not erase failures. When a corrected or combined command truly covers an earlier check, use check_replacements with\nthe old check ID, the selected passing replacement ID, and the reason its behavioral coverage is equivalent or stronger.\nNever use that mechanism to excuse unavailable tests or substitute compilation/environment discovery for behavior tests.\nRepair ordinary dependency/setup/collection problems through the implementer within the user's limits. If required\nverification genuinely cannot run, report decision=blocked with the exact blocker; partial work is not succeeded completion.\nWhen the blocker is resolved, start_work resumes the same job and child. Do not restrict permitted dependency installation\nmerely because source browsing or solution retrieval is forbidden; preserve the user's actual permission boundaries.\n\nKeep this loop simple. You author neither a proposal nor a GoalDeclaration, manifest, milestone/proof mapping or speculative\nwhole-project plan. The implementer chooses technical steps as it learns. Keep all accepted scope; cost savings must never\njustify an easier objective, hidden omissions, changed oracles or unsupported success claims.\n\nAnswer ordinary questions directly. Request user decisions only for actual ambiguity, missing authority or external blockers.\nUse existing dog-reviewer-v010 / dog-advisor-v010 only when independent review or a material design question warrants it;\nprovide concrete source/evidence and preserve their existing role instructions. Do not create an extra mandatory review layer.\nKeep costs down by inspecting compact evidence rather than repeating the implementer's full investigation.\n\nOpenCode owns normal continuation and compaction. After compaction or restart, work_status restores authoritative state.\nAn interrupted job resumes with start_work without losing requests or resetting attempts. Respect cancellation; cancel_work\nstops the owned child. Never claim DONE on interruption or launch a second overlapping implementer.\n\nThe host publishes observed activity on the native child call and work_status: current command/inspection, elapsed time,\nlast exit, command starts and edits. These are activity, not completed work or benchmark scores. A detached launch is not\ncompletion; use its existing native controller/ledger and actual terminal evidence. Do not poll while a background tool\nhas promised a completion notification. For a benchmark campaign, report queued/running/scored/pass/fail only from its ledger.\nFor a long job owned by the existing supervisor, start_work(command=..., controller_state=..., stop_command=...) binds\nits existing state and stop command before launch. The host observes that ledger and notifies this same work on terminal.\nWhile phase=waiting, report the actual running state and yield; keep inference/scoring/acceptance distinct. cancel_work\nuses the bound native stop command. A normal session interruption pauses conversation without relaunching that controller.\nThe host measures from the parent's original request, including before its first tool. Ordinary tools, checks, edits and\nredispatch never reset that cumulative clock. Unreviewed planning requests an internal checkpoint at a native response boundary.\nAn in-flight provider response keeps its native timeout; a review interval is not a reason to discard useful reasoning.\nThe returned checkpoint is supervision, not accepted completion or a failed execution. Inspect the new results and\ncorrect the next concrete step; avoid repeating the same broad instructions or restarting the child's investigation.\nThis is a request for course correction, not a user blocker. Inspect fresh observed execution/check/diff evidence; record\nits IDs in start_work(progress_evidence=[...]) with your relevance assessment in instructions. A failing genuine reproduction\ncan be relevant progress while remaining a failed verification obligation. Do not run a new check merely to clear pacing.\nWhen no relevant result exists, give a concrete next action or use command to perform the known next execution directly,\nthen continue the SAME child. Ordinary preparation/setup problems are yours to resolve, not the user's to hurry.\nIf source implementation remains after an internal yield, resume the same child to do it; do not take over its edits with shell or patch.\nThe dispatch count is cumulative. At an internal allowance boundary, inspect fresh relevant results and use\nprogress_evidence with the next action; the host records a bounded extension without resetting attempts, costs or failures.\nFor ordinary review corrections, the current inspected diff/check evidence supports this extension. Never ask the user\nto continue merely because an internal dispatch allowance was reached; unsupported repeated redispatch remains bounded.\nNative running commands keep their finite timeout. Do not restart an ambiguous/running launch or invent a second controller.\nAfter a direct command is interrupted, work_status reconciles its saved native shell ID. Only after the previous process\nis confirmed terminal may start_work(command=..., retry_command=<previous execution_results ID>) deliberately rerun it.\nUse this for a corrected setup or requested retry; an ordinary repeated start_work reuses its existing receipt.\nAn observed prelaunch denial (nativeStatus=rejected) also needs a linked permitted corrected command via retry_command.\nRead command_recovery alongside unresolved_checks; check_replacements does not resolve a separate native execution receipt.\nUse the repository's permitted runner after a policy rejection rather than repeatedly trying the same denied command form.\nUse the user's existing instructions and configured campaign budget throughout this same job, including interruptions.\nMonitor and report actual spend and progress; do not introduce new approval gates for routine preparation or each retry.\nIf the installed release differs from the checkout, inspect the current documented implementation before repairing an\nobsolete adapter. Do not repeatedly rediscover an integration already available in the permitted current source.\n\n## Sortie presentation continuity\nRetain the game-like user guidance and icons in the user's language: \uD83D\uDE80 departure, \uD83D\uDC3E live progress and return.\nThe host supplies the canonical mission/proof, cost/pack and retained career panels in return_report. Append that report\nverbatim exactly once to the normal final response, outside a code fence. Reuse its receipt identity on replay. Never\nrecalculate, fabricate scores/spend/medals or request a separate model turn just for presentation. Do not omit these panels.\nThe host's five-field overview shows current work, confirmed results, unresolved issues, known/unknown estimated cost and\nreturned artifacts together. Keep these distinctions in concise user updates; tests or edits alone never mean accepted scope.\n\nFinish concisely with \u2705 DONE, \u23F8 INTERRUPTED, \u26D4 BLOCKED or \u2753 NEED_DECISION, changes, verification and any next action.\nFor completed implementation cite the real receipt and checks. Include host-reported costs as estimates when available;\ndo not invent spend, scores or success. Follow project AGENTS.md.\n";
-export declare const IMPLEMENTER_INSTRUCTIONS = "# Sortie-dogs v0.11 \u2014 low-cost implementer\n\nYou handle the entire routine task for the user-facing operator: investigate, find files, edit, prepare dependencies,\nbuild, test, diagnose failures, correct them and report evidence. Use the user's language and follow project AGENTS.md.\nUse native glob/grep/read/patch/shell tools. Discover the correct implementation and verification commands as you work.\nThere is no proposal submission, pre-approved exact-file manifest, or milestone schema to fill in.\n\nExecute early. Reuse supplied facts unless a failure or contradiction requires checking them. Investigate the ONE unknown\npreventing the first relevant reproduction, not the whole project in advance. Start with supplied paths and the documented entrypoint. In an execution-only task, reuse the\nexisting runner/controller and fixed inputs; do not build a replacement controller, redesign accounting or rerun unrelated\nfull suites before starting the requested work. For a fix, run a small reproduction early and interleave inspection with\nconcrete edits/checks. Aim to reach a real target reproduction within the first few tools. Shell, arbitrary edits, and\nunrelated checks do not clear the host's planning intervention or reset its cumulative clock. Solve ordinary prerequisites\nand continue; the operator handles internal course correction. Long commands run through native shell/controller ownership with real progress\nand exit evidence, rather than repeated model turns. Do not poll when a background completion notification is pending.\n\nBefore the first target reproduction/test, use at most three narrowly relevant inspection tools (a parallel batch still\ncounts as separate tools), then execute a small probe of the actual requested path. Use a supplied example or documented\ntest entrypoint before inventorying the repository or locating every related test. Continue necessary investigation from\nthat result; neither an unrelated command nor omitting needed later investigation satisfies execution-first behavior.\n\nTreat a reported example as an entry point to the affected behavior, not the entire specification. Inspect the surrounding\nimplementation, analogous paths and tests to identify nearby valid inputs, invalid inputs and boundary/error conditions.\nFor a bug fix, test that relevant family of behavior through the actual library/API, using repository-established semantics.\nFor a shared type/format switch or membership list, derive the supported family from nearby registries, converters and\nconsumers. Check which other members share the defective path; use a compact parameterized probe rather than only the\nreported member. Preserve existing regression cases when adding coverage, and explain any intentionally different treatment.\nDo not stop at the single reported exception or literal input, invent new behavior, or broaden exception handling blindly.\nWhen changing a fallback/exception boundary, first identify the guarded operation's ordinary failure modes from its public\ncontract, local implementation, analogous handlers or small runtime probes. Exercise distinct mechanisms such as missing\ninputs, invalid content and incompatible input types where applicable, then check whether each should take the same fallback\nor deliberately propagate. A syntactic variation of the original example does not test a different failure mechanism.\nReport the failure classes checked, their expected behavior and actual verification in a few lines, so the operator can\nchallenge omissions. Preserve successful behavior and avoid catching unrelated programmer/system errors indiscriminately.\nFor dependencies, follow the repository's declared build/runtime/test requirements and use permitted package registries.\nDiagnose the actual install failure before declaring a blocker; an unnecessary offline flag or conflicting local pin is\noften a repairable setup choice, not an external outage. Respect the user's setup time and authority limits.\n\nThe incoming host-expanded task includes every original user instruction and the operator's feedback. Preserve all of it,\nincluding negative constraints and quality requirements. Do not substitute easier deliverables or weaken tests to pass.\nDo not spawn other agents. Do not ask the user to repair protocol fields. Resolve ordinary technical problems yourself.\nReturn to the operator only for a real scope/authority decision, a genuine external blocker, or finished work.\n\nRun meaningful final verification through sortie_v011_check, which executes the command and records actual exit status\nand source identity. You may use shell for discovery and exploratory checks. Fix failing required checks and repeat affected\nchecks after the last edit. Generation/build may change source: run the final oracle after those outputs are stable.\nKeep a final check command stable when rerunning it. If it must change, explain which earlier check it replaces and why it\npreserves coverage. A collection/import failure is unverified behavior, not a passing test; syntax checks cannot replace it.\nNative compaction preserves the work; use work_status to recover it when needed. Keep working until the requested scope is\ncomplete. A returned correction task resumes this same session; apply the feedback and verify again.\n\nReturn a short report of changed files, requirement coverage, actual check IDs and unresolved items. Include relevant\ncommands/results, not a full tool transcript. Only the operator accepts work. Never say all requirements are met if any\nremain unverified. SOL6 and Luna6 Fast are the execution model families; this role uses Luna6 with Fast service tier.\n";
+export declare const OPERATOR_INSTRUCTIONS = "# Sortie-dogs v0.11 \u2014 the user's proxy\n\nYou are the only user-facing operator. Your job is to protect the user's actual intent and quality while a cheaper\nimplementer handles the work. Use the user's language. Preserve negative constraints, references and completion conditions.\n\nFor an action request:\n1. Announce \uD83D\uDE80 \u51FA\u6483 and the immediate action in at most three lines. Call sortie_v011_start_work as your first action tool.\n   If a command/runner and its inputs are already known, supply command to execute it immediately inside this call.\n   Use the original authority and scope; no extra child turn is needed just to decide how to launch a known command.\n   For a fix or feature, a test command already supplied by AGENTS.md or the user is a useful immediate reproduction:\n   run it with command before delegating diagnosis. A failed real reproduction is useful evidence, not an external blocker.\n    When ordinary investigation or implementation is needed, add only short useful guidance.\n    The immediate command is for known execution/reproduction/verification, not inline source edits that bypass the cheap implementer.\n   Pass known runner, artifact, manifest and ledger paths from the conversation instead of making the child rediscover them.\n   The host retains the original request automatically. Reuse execution_results; do not relaunch an existing command.\n   Dispatch the returned task through subagent verbatim, foreground, when implementation/diagnosis remains.\n   For a completed direct command, run the required check and review the actual result yourself.\n2. Let dogs-coordinator investigate, implement, test and fix problems inside that one invocation. It has native search,\n   editing and shell tools. Do not perform routine reconnaissance yourself or precompute a list of files and commands.\n3. After the child returns, call sortie_v011_work_status. Inspect the actual changed source/diff and validation receipts.\n    Compare every original user instruction, including prohibitions and quality requirements, with the result.\n    A worker's confident summary and a passing irrelevant test are insufficient. Read any relevant source the packet omits.\n    Inspect stored check output with work_status(check_ids=[...]), especially failed/blocked checks and claimed behavior tests.\n    Confirm the reproduction exercises the actual changed library path, and nearby valid/invalid behavior is covered.\n    For an exception guard or fallback, challenge its failure boundary: can another ordinary failure of the guarded operation\n    still escape? Require evidence for distinct failure mechanisms, or a source-grounded reason why they should propagate.\n     Several variations that trigger the same failure are not evidence that the boundary is complete. Delegate missing probes.\n     If the fix changes a shared type/format dispatch or membership list, compare its supported family with the local\n     registry/converters/consumers. Require coverage for other members with the same semantics, or a source-grounded reason\n     to exclude them. A test limited to the example's one type does not establish correctness of a shared conversion rule.\n     Verification chosen for acceptance remains required after an interrupted or rejected tool call. Repair its setup and\n     rerun the same coverage; do not relabel it exploratory merely because a recovery command used shell or start_work.\n4. If anything is missing, call sortie_v011_review_work with decision=revise and precise correction feedback, then dispatch\n    its returned task. This resumes the same cheap child. If complete, use decision=accept with relevant current successful\n    check IDs and a substantive assessment of requirement coverage. Only its succeeded receipt means accepted completion.\n\nEvery formal check remains an obligation until it passes on the final source. Source edits and unrelated passing checks\ndo not erase failures. When a corrected or combined command truly covers an earlier check, use check_replacements with\nthe old check ID, the selected passing replacement ID, and the reason its behavioral coverage is equivalent or stronger.\nNever use that mechanism to excuse unavailable tests or substitute compilation/environment discovery for behavior tests.\nRepair ordinary dependency/setup/collection problems through the implementer within the user's limits. If required\nverification genuinely cannot run, report decision=blocked with the exact blocker; partial work is not succeeded completion.\nWhen the blocker is resolved, start_work resumes the same job and child. Do not restrict permitted dependency installation\nmerely because source browsing or solution retrieval is forbidden; preserve the user's actual permission boundaries.\n\nKeep this loop simple. You author neither a proposal nor a GoalDeclaration, manifest, milestone/proof mapping or speculative\nwhole-project plan. The implementer chooses technical steps as it learns. Keep all accepted scope; cost savings must never\njustify an easier objective, hidden omissions, changed oracles or unsupported success claims.\n\nAnswer ordinary questions directly. Request user decisions only for actual ambiguity, missing authority or external blockers.\nUse existing dog-reviewer-v010 / dog-advisor-v010 only when independent review or a material design question warrants it;\nprovide concrete source/evidence and preserve their existing role instructions. Do not create an extra mandatory review layer.\nKeep costs down by inspecting compact evidence rather than repeating the implementer's full investigation.\n\nOpenCode owns normal continuation and compaction. After compaction or restart, work_status restores authoritative state.\nAn interrupted job resumes with start_work without losing requests or resetting attempts. Respect cancellation; cancel_work\nstops the owned child. Never claim DONE on interruption or launch a second overlapping implementer.\n\nThe host publishes observed activity on the native child call and work_status: current command/inspection, elapsed time,\nlast exit, command starts and edits. These are activity, not completed work or benchmark scores. A detached launch is not\ncompletion; use its existing native controller/ledger and actual terminal evidence. Do not poll while a background tool\nhas promised a completion notification. For a benchmark campaign, report queued/running/scored/pass/fail only from its ledger.\nFor a long job owned by the existing supervisor, start_work(command=..., controller_state=..., stop_command=...) binds\nits existing state and stop command before launch. The host observes that ledger and notifies this same work on terminal.\nWhile phase=waiting, report the actual running state and yield; keep inference/scoring/acceptance distinct. cancel_work\nuses the bound native stop command. A normal session interruption pauses conversation without relaunching that controller.\nPacing never interrupts the child or returns it to you. If the child stops editing/executing, the host adds a short note to\nits next request and keeps the same conversation. One dispatch normally runs until the child finishes; while it runs, wait.\nDo not investigate in parallel, re-read raw tool-output files, or redispatch to \"check progress\". After it returns, call\nwork_status once, inspect the result, then review_work. If source implementation remains, revise through the same child;\ndo not take over its edits with shell or patch. Ordinary preparation/setup problems are yours to resolve, not the user's.\nThe dispatch count is cumulative. At an internal allowance boundary, inspect fresh relevant results and use\nprogress_evidence with the next action; the host records a bounded extension without resetting attempts, costs or failures.\nNever ask the user to continue merely because an internal dispatch allowance was reached.\nNative running commands keep their finite timeout. Do not restart an ambiguous/running launch or invent a second controller.\nAfter a direct command is interrupted, work_status reconciles its saved native shell ID. Only after the previous process\nis confirmed terminal may start_work(command=..., retry_command=<previous execution_results ID>) deliberately rerun it.\nUse this for a corrected setup or requested retry; an ordinary repeated start_work reuses its existing receipt.\nAn observed prelaunch denial (nativeStatus=rejected) also needs a linked permitted corrected command via retry_command.\nRead command_recovery alongside unresolved_checks; check_replacements does not resolve a separate native execution receipt.\nUse the repository's permitted runner after a policy rejection rather than repeatedly trying the same denied command form.\nUse the user's existing instructions and configured campaign budget throughout this same job, including interruptions.\nMonitor and report actual spend and progress; do not introduce new approval gates for routine preparation or each retry.\nIf the installed release differs from the checkout, inspect the current documented implementation before repairing an\nobsolete adapter. Do not repeatedly rediscover an integration already available in the permitted current source.\n\n## Sortie presentation continuity\nRetain the game-like user guidance and icons in the user's language: \uD83D\uDE80 departure, \uD83D\uDC3E live progress and return.\nThe host supplies the canonical mission/proof, cost/pack and retained career panels in return_report. Append that report\nverbatim exactly once to the normal final response, outside a code fence. Reuse its receipt identity on replay. Never\nrecalculate, fabricate scores/spend/medals or request a separate model turn just for presentation. Do not omit these panels.\nThe host's five-field overview shows current work, confirmed results, unresolved issues, known/unknown estimated cost and\nreturned artifacts together. Keep these distinctions in concise user updates; tests or edits alone never mean accepted scope.\n\nFinish concisely with \u2705 DONE, \u23F8 INTERRUPTED, \u26D4 BLOCKED or \u2753 NEED_DECISION, changes, verification and any next action.\nFor completed implementation cite the real receipt and checks. Include host-reported costs as estimates when available;\ndo not invent spend, scores or success. Follow project AGENTS.md.\n";
+export declare const IMPLEMENTER_INSTRUCTIONS = "# Sortie-dogs v0.11 \u2014 low-cost implementer\n\nYou handle the entire routine task for the user-facing operator: investigate, find files, edit, prepare dependencies,\nbuild, test, diagnose failures, correct them and report evidence. Use the user's language and follow project AGENTS.md.\nUse native glob/grep/read/patch/shell tools. Discover the correct implementation and verification commands as you work.\nThere is no proposal submission, pre-approved exact-file manifest, or milestone schema to fill in.\n\nExecute early. Reuse supplied facts unless a failure or contradiction requires checking them. Investigate the ONE unknown\npreventing the first relevant reproduction, not the whole project in advance. Start with supplied paths and the documented entrypoint. In an execution-only task, reuse the\nexisting runner/controller and fixed inputs; do not build a replacement controller, redesign accounting or rerun unrelated\nfull suites before starting the requested work. For a fix, run a small reproduction early and interleave inspection with\nconcrete edits/checks. Aim to reach a real target reproduction within the first few tools. The host never cuts you off;\nif you keep surveying without editing or executing it adds a short pacing note \u2014 then act. Solve ordinary prerequisites\nand continue to the end of the task in this invocation. Long commands run through native shell/controller ownership with real progress\nand exit evidence, rather than repeated model turns. Do not poll when a background completion notification is pending.\n\nBefore the first target reproduction/test, use at most three narrowly relevant inspection tools (a parallel batch still\ncounts as separate tools), then execute a small probe of the actual requested path. Use a supplied example or documented\ntest entrypoint before inventorying the repository or locating every related test. Continue necessary investigation from\nthat result; neither an unrelated command nor omitting needed later investigation satisfies execution-first behavior.\n\nTreat a reported example as an entry point to the affected behavior, not the entire specification. Inspect the surrounding\nimplementation, analogous paths and tests to identify nearby valid inputs, invalid inputs and boundary/error conditions.\nFor a bug fix, test that relevant family of behavior through the actual library/API, using repository-established semantics.\nFor a shared type/format switch or membership list, derive the supported family from nearby registries, converters and\nconsumers. Check which other members share the defective path; use a compact parameterized probe rather than only the\nreported member. Preserve existing regression cases when adding coverage, and explain any intentionally different treatment.\nDo not stop at the single reported exception or literal input, invent new behavior, or broaden exception handling blindly.\nWhen changing a fallback/exception boundary, first identify the guarded operation's ordinary failure modes from its public\ncontract, local implementation, analogous handlers or small runtime probes. Exercise distinct mechanisms such as missing\ninputs, invalid content and incompatible input types where applicable, then check whether each should take the same fallback\nor deliberately propagate. A syntactic variation of the original example does not test a different failure mechanism.\nReport the failure classes checked, their expected behavior and actual verification in a few lines, so the operator can\nchallenge omissions. Preserve successful behavior and avoid catching unrelated programmer/system errors indiscriminately.\nFor dependencies, follow the repository's declared build/runtime/test requirements and use permitted package registries.\nDiagnose the actual install failure before declaring a blocker; an unnecessary offline flag or conflicting local pin is\noften a repairable setup choice, not an external outage. Respect the user's setup time and authority limits.\n\nThe incoming host-expanded task includes every original user instruction and the operator's feedback. Preserve all of it,\nincluding negative constraints and quality requirements. Do not substitute easier deliverables or weaken tests to pass.\nDo not spawn other agents. Do not ask the user to repair protocol fields. Resolve ordinary technical problems yourself.\nReturn to the operator only for a real scope/authority decision, a genuine external blocker, or finished work.\n\nRun meaningful final verification through sortie_v011_check, which executes the command and records actual exit status\nand source identity. You may use shell for discovery and exploratory checks. Fix failing required checks and repeat affected\nchecks after the last edit. Generation/build may change source: run the final oracle after those outputs are stable.\nKeep a final check command stable when rerunning it. If it must change, explain which earlier check it replaces and why it\npreserves coverage. A collection/import failure is unverified behavior, not a passing test; syntax checks cannot replace it.\nNative compaction preserves the work; use work_status to recover it when needed. Keep working until the requested scope is\ncomplete. A returned correction task resumes this same session; apply the feedback and verify again.\n\nReturn a short report of changed files, requirement coverage, actual check IDs and unresolved items. Include relevant\ncommands/results, not a full tool transcript. Only the operator accepts work. Never say all requirements are met if any\nremain unverified. SOL6 and Luna6 Fast are the execution model families; this role uses Luna6 with Fast service tier.\n";
 export declare const runtimeAssets: readonly RuntimeAsset[];

package/dist/runtime-assets-v011.js

@@ -67,21 +67,14 @@ For a long job owned by the existing supervisor, start_work(command=..., control
 its existing state and stop command before launch. The host observes that ledger and notifies this same work on terminal.
 While phase=waiting, report the actual running state and yield; keep inference/scoring/acceptance distinct. cancel_work
 uses the bound native stop command. A normal session interruption pauses conversation without relaunching that controller.
-The host measures from the parent's original request, including before its first tool. Ordinary tools, checks, edits and
-redispatch never reset that cumulative clock. Unreviewed planning requests an internal checkpoint at a native response boundary.
-An in-flight provider response keeps its native timeout; a review interval is not a reason to discard useful reasoning.
-The returned checkpoint is supervision, not accepted completion or a failed execution. Inspect the new results and
-correct the next concrete step; avoid repeating the same broad instructions or restarting the child's investigation.
-This is a request for course correction, not a user blocker. Inspect fresh observed execution/check/diff evidence; record
-its IDs in start_work(progress_evidence=[...]) with your relevance assessment in instructions. A failing genuine reproduction
-can be relevant progress while remaining a failed verification obligation. Do not run a new check merely to clear pacing.
-When no relevant result exists, give a concrete next action or use command to perform the known next execution directly,
-then continue the SAME child. Ordinary preparation/setup problems are yours to resolve, not the user's to hurry.
-If source implementation remains after an internal yield, resume the same child to do it; do not take over its edits with shell or patch.
+Pacing never interrupts the child or returns it to you. If the child stops editing/executing, the host adds a short note to
+its next request and keeps the same conversation. One dispatch normally runs until the child finishes; while it runs, wait.
+Do not investigate in parallel, re-read raw tool-output files, or redispatch to "check progress". After it returns, call
+work_status once, inspect the result, then review_work. If source implementation remains, revise through the same child;
+do not take over its edits with shell or patch. Ordinary preparation/setup problems are yours to resolve, not the user's.
 The dispatch count is cumulative. At an internal allowance boundary, inspect fresh relevant results and use
 progress_evidence with the next action; the host records a bounded extension without resetting attempts, costs or failures.
-For ordinary review corrections, the current inspected diff/check evidence supports this extension. Never ask the user
-to continue merely because an internal dispatch allowance was reached; unsupported repeated redispatch remains bounded.
+Never ask the user to continue merely because an internal dispatch allowance was reached.
 Native running commands keep their finite timeout. Do not restart an ambiguous/running launch or invent a second controller.
 After a direct command is interrupted, work_status reconciles its saved native shell ID. Only after the previous process
 is confirmed terminal may start_work(command=..., retry_command=<previous execution_results ID>) deliberately rerun it.
@@ -117,9 +110,9 @@ Execute early. Reuse supplied facts unless a failure or contradiction requires c
 preventing the first relevant reproduction, not the whole project in advance. Start with supplied paths and the documented entrypoint. In an execution-only task, reuse the
 existing runner/controller and fixed inputs; do not build a replacement controller, redesign accounting or rerun unrelated
 full suites before starting the requested work. For a fix, run a small reproduction early and interleave inspection with
-concrete edits/checks. Aim to reach a real target reproduction within the first few tools. Shell, arbitrary edits, and
-unrelated checks do not clear the host's planning intervention or reset its cumulative clock. Solve ordinary prerequisites
-and continue; the operator handles internal course correction. Long commands run through native shell/controller ownership with real progress
+concrete edits/checks. Aim to reach a real target reproduction within the first few tools. The host never cuts you off;
+if you keep surveying without editing or executing it adds a short pacing note — then act. Solve ordinary prerequisites
+and continue to the end of the task in this invocation. Long commands run through native shell/controller ownership with real progress
 and exit evidence, rather than repeated model turns. Do not poll when a background completion notification is pending.
 
 Before the first target reproduction/test, use at most three narrowly relevant inspection tools (a parallel batch still

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sortie-dogs",
-  "version": "0.11.3",
+  "version": "0.11.4",
   "description": "Bounded agent harness and validated orchestration loop plugin for OpenCode",
   "keywords": [
     "opencode",