sortie-dogs 0.11.2 → 0.11.3

package/README.md

@@ -69,6 +69,21 @@ is an internal implementation child. The default V2 package export and
 
 ## How v0.11 works
 
+### Feedback and supervision
+
+Send corrections in the same conversation. The original request and subsequent
+instructions are retained across interruptions and compaction and are delivered
+to the same implementation child. The operator inspects real results before
+continuing or accepting the work. Native controller ledgers can keep long jobs
+running and return control to that operator when they finish.
+
+Progress checkpoints wait for a native response boundary; an in-flight provider
+response keeps its native timeout. A checkpoint does not mean the user's task is
+complete. Required checks, attempts and known/unknown costs remain cumulative.
+Feedback retention is per job: the v0.11 loop does not automatically apply the
+v0.10 reflection policy to future jobs. Reproducible product feedback is recorded
+in [the v0.11.2 dogfooding incident](docs/feedback/v0112-redispatch-loop.md).
+
 1. **Keep the original request.** The host retains the user's words, attachments,
    selected skills and subsequent instructions in durable plugin storage.
 2. **Delegate practical work.** The operator adds short guidance and dispatches

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.2-user-proxy-execution-first-v1";
+export declare const V011_RUNTIME_ASSET_VERSION = "0.11.3-cooperative-progress-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.2-user-proxy-execution-first-v1";
+export const V011_RUNTIME_ASSET_VERSION = "0.11.3-cooperative-progress-v1";

package/dist/core/work-loop.js

@@ -494,6 +494,9 @@ export class WorkLoop {
                     return;
                 progress.active = progress.active.filter(item => item.id !== activity.id);
                 progress.last = { ...active, ...result };
+                // Activity is visible liveness, not reviewed progress or accepted work.
+                // Keep the original request and review clocks unchanged.
+                progress.lastActionAt = Date.now();
                 if (result.status === "completed" && activity.tool === "patch")
                     progress.edits++;
                 if (result.status === "completed" && result.exit !== null && activity.tool === "shell")

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

@@ -48,6 +48,7 @@ export function createUserProxyPlugin() {
             let observingControllers = false;
             const nativeCommands = new Map();
             const childTurns = new Map();
+            const inFlightRequests = new Set(), localYields = new Set();
             const launchPermissions = new Map();
             await context.permission.hook("evaluate", async (event) => {
                 // Observe the native permission decision without changing it. Keeping the
@@ -78,6 +79,13 @@ export function createUserProxyPlugin() {
                 if (await root(id) !== id)
                     throw new Error("work-operator-only");
             };
+            const observePrimaryRequest = async (event) => {
+                if (event.kind && event.kind !== "primary")
+                    return;
+                const id = String(event.sessionID), session = await info(id);
+                if ([primary, worker].includes(session.agent))
+                    inFlightRequests.add(id);
+            };
             async function history(id) {
                 if (!context.message)
                     return (await context.session.context({ sessionID: id })).filter(isRecord);
@@ -354,6 +362,10 @@ export function createUserProxyPlugin() {
                             deferred = true;
                             return;
                         }
+                        if (inFlightRequests.has(id)) {
+                            deferred = true;
+                            return;
+                        }
                         if (native.time?.idle >= since || work?.userStopped || work?.phase === "running" || work?.phase === "waiting" || work?.progress?.active.length || work?.phase === "cancelled")
                             return;
                         const progress = await loop.progress(id);
@@ -417,13 +429,15 @@ export function createUserProxyPlugin() {
                                 description: `🐾 ${progress.phase} · ${Math.floor(progress.elapsed_ms / 1000)}s · ${progress.summary}`,
                                 sortie_progress: progress });
                             const reason = current.phase === "running" ? progressLimit(current.progress, Date.now(), planningMs, discoveryCalls) : null;
-                            // Prefer the next native request boundary: cutting a recently submitted
-                            // response discards useful reasoning and can lose provider usage. This is
-                            // one fixed grace beyond the cumulative deadline, never a reset by activity.
+                            // 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 && (turn === undefined || Date.now() >= deadline + grace || Date.now() - turn >= planningMs) && await loop.stall(id, work.callID, reason)) {
+                            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 });
@@ -448,13 +462,31 @@ 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)
+                            if (current?.child) {
                                 childTurns.delete(current.child);
+                                inFlightRequests.delete(current.child);
+                            }
                             await pending;
                         }
                     };
@@ -644,6 +676,7 @@ export function createUserProxyPlugin() {
                     return;
                 }
                 const owner = await root(id);
+                inFlightRequests.delete(id);
                 if (id === owner)
                     thinking.delete(id);
                 if (session.agent === worker) {
@@ -696,12 +729,15 @@ export function createUserProxyPlugin() {
                     throw new Error("Sortie v0.11 requires SOL6 or Luna6. Set the selected session and auxiliary compaction/title agents to these models; reviewer/advisor settings are independent.");
                 }
                 const owner = await root(String(event.sessionID)), work = await loop.current(owner);
+                if (event.kind !== "auxiliary")
+                    inFlightRequests.delete(String(event.sessionID));
                 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());
@@ -811,6 +847,8 @@ export function createUserProxyPlugin() {
                     await retainUsage(work, await costs(work));
             };
             await context.session.hook("http.request", async (event) => {
+                if (event.request instanceof Request && event.request.method === "POST")
+                    await observePrimaryRequest(event);
                 const entry = event.request instanceof Request && event.request.method === "POST" ? await beginAuxiliary(event) : undefined;
                 if (entry && event.request instanceof Request)
                     auxiliaryRequests.set(event.request, entry);
@@ -834,8 +872,10 @@ export function createUserProxyPlugin() {
                         .catch(error => console.warn("[sortie-dogs-v011] auxiliary usage", error));
             });
             await context.session.hook("experimental.ws.send", async (event) => {
-                if (typeof event.frame === "string" && JSON.parse(event.frame).type === "response.create")
+                if (typeof event.frame === "string" && JSON.parse(event.frame).type === "response.create") {
+                    await observePrimaryRequest(event);
                     await beginAuxiliary(event);
+                }
                 if (!await fastRequest(event) || typeof event.frame !== "string")
                     return;
                 const frame = JSON.parse(event.frame);
@@ -906,6 +946,7 @@ export function createUserProxyPlugin() {
                     if (typeof id !== "string")
                         continue;
                     if (["session.execution.succeeded", "session.idle"].includes(String(event.type))) {
+                        inFlightRequests.delete(id);
                         thinking.delete(id);
                         try {
                             const session = await info(id);
@@ -922,6 +963,7 @@ export function createUserProxyPlugin() {
                     }
                     if (!["session.execution.interrupted", "session.execution.failed"].includes(String(event.type)))
                         continue;
+                    inFlightRequests.delete(id);
                     if (internalStops.delete(id))
                         continue;
                     try {

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 yields internally after a bounded interval/call count.\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.\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 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 runtimeAssets: readonly RuntimeAsset[];

package/dist/runtime-assets-v011.js

@@ -68,7 +68,10 @@ its existing state and stop command before launch. The host observes that ledger
 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 yields internally after a bounded interval/call count.
+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.
@@ -86,6 +89,10 @@ Use this for a corrected setup or requested retry; an ordinary repeated start_wo
 An observed prelaunch denial (nativeStatus=rejected) also needs a linked permitted corrected command via retry_command.
 Read command_recovery alongside unresolved_checks; check_replacements does not resolve a separate native execution receipt.
 Use the repository's permitted runner after a policy rejection rather than repeatedly trying the same denied command form.
+Use the user's existing instructions and configured campaign budget throughout this same job, including interruptions.
+Monitor and report actual spend and progress; do not introduce new approval gates for routine preparation or each retry.
+If the installed release differs from the checkout, inspect the current documented implementation before repairing an
+obsolete adapter. Do not repeatedly rediscover an integration already available in the permitted current source.
 
 ## Sortie presentation continuity
 Retain the game-like user guidance and icons in the user's language: 🚀 departure, 🐾 live progress and return.

package/package.json

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