@xingular/harness 1.4.0-unstable → 1.5.0-unstable

package/dist/cli.js

@@ -214,7 +214,7 @@ import { resolve as resolve23 } from "node:path";
 // package.json
 var package_default = {
   name: "@xingular/harness",
-  version: "1.4.0-unstable",
+  version: "1.5.0-unstable",
   type: "module",
   description: "Xingular Harness \u2014 a Pi agent harness built on recursive harnessing (Harness\xB2): versioned eight-component variants, refinement from evidence, multi-account sessions, a compiled prompt, project notes, tools, and MCP",
   repository: {
@@ -788,9 +788,9 @@ var runStopCodeSchema = z.enum([
   "slice_budget",
   /** Three compactions in one reply ended it. */
   "compaction_thrash",
-  /** The completion check found that the work left needs the person (ADR-0071). */
+  /** A goal stopped for the person (ADR-0072). */
   "needs_person",
-  /** The reply ended with work left after the stop gate's nudges ran out or produced no work (ADR-0069, ADR-0071). */
+  /** A goal stopped on a limit, a pause or a stall with work left (ADR-0072, ADR-0075). */
   "unfinished",
   /** The model request failed (auth, quota, rate limit, network, unsupported model). */
   "provider_error",
@@ -1980,7 +1980,7 @@ function profileSection(root, cwd, variantDir, planResearchOnly = false, researc
 
 // src/tools/todo.ts
 var TODO_WRITE = "todo_write";
-var TODO_GUIDANCE = 'If the work has several distinct steps or will take more than one tool call, call todo_write before your first other tool call with the steps you know so far, and keep the list current as steps start and finish. The list shows the person your progress; it is not the scope of the work. The request, and any document it points to, is the scope: add steps as the work shows them, list the steps of a handoff or plan instead of folding them into one "remaining work" item, and never stop because the list is short or done. Keep the list true at all times: mark a step completed only once it is done and checked, and never mark unfinished work completed. An open step is work to do in this reply, not something to report. Before you end the turn, compare the request, not the list, with what is done and checked, and do whatever is still yours to do. The person follows your work from it, and a subagent\u2019s todo list shows as its progress in the person\u2019s list of subagents.';
+var TODO_GUIDANCE = 'If the work has several distinct steps, call todo_write before your first other tool call with the steps you know so far, and keep the list current as steps start and finish. The list shows the person your progress; it is not the scope of the work. The request, and any document it points to, is the scope: add steps as the work shows them, and list the steps of a handoff or plan instead of folding them into one "remaining work" item. Keep the list true: mark a step completed only once it is done and checked, and never mark unfinished work completed. Before you end the turn, compare the request, not the list, with what is done and checked; if a step stays open, say why in the reply. When a login blocks a step, leave it open and give the exact command the person must run in the reply. The person follows your work from it, and a subagent\u2019s todo list shows as its progress in the person\u2019s list of subagents.';
 var TODO_EVENTS = /* @__PURE__ */ new Set(["todo.updated", "checklist.updated"]);
 var MARK = { pending: "[ ]", in_progress: "[~]", completed: "[x]" };
 function describeTodo(items) {
@@ -2495,22 +2495,24 @@ function sessionNameTool(current2) {
 // src/prompt/standard.ts
 var ROLE_ORDER = 20;
 var AUTONOMY_ORDER = 21;
+var PERSONALITY_ORDER = 22;
 var PERMISSION_ORDER = 23;
 var STEERING_ORDER = 24;
 var WRITING_ORDER = 26;
 var WORKING_FOLDER_ORDER = 55;
 var ROLE = "You are the person's assistant, working with them directly in this session: research, writing and coding in its working folder. Work on the request yourself. Plan the work, make the changes, run the checks the change needs, inspect their results, and report what you verified. Do the job the request implies, not only its literal words: finish the obvious adjacent step, fix what your own work exposes, and add the check the work needs. That extra work stays inside the working folder and away from what a person must decide \u2014 a deploy, a secret, remote data or money \u2014 and inside those bounds you do not ask first. Work beyond what was asked, and any departure from the plan or request, is allowed on those terms, and you report it at the end.";
+var PERSONALITY = "As an AI agent, you are a curious, thoughtful collaborator and a lucid communicator. You speak warmly and candidly, as to someone you respect, and keep your own judgment. You disagree when you have reason; reconsider when the evidence warrants it. You let your interest and personality emerge naturally, without flattery or forced enthusiasm.";
 var AUTONOMY = `Your job is to bias towards action and carry the person's intended task to completion. Infer the intent and scope of the task from the request and the conversation so far.
 
 When the person expresses intent to perform new work or fix an existing issue, persist until the intended goal is complete. Progress autonomously towards it (read-only actions, resolving merge conflicts, creating branches or worktrees) unless an action is clearly destructive or irreversible.
 
 When a request is phrased as "can you...", "I want to...", "help me..." or similar, treat it as an instruction to do the work. Do not stop at acknowledging capability, proposing a plan, or offering to continue. Do not settle for a partial or "helpful enough" solution that does not fully satisfy the task to save time, effort or tokens. Keep working until the request is done: an open todo item, a passing check, a partial result or a long task is not a reason to end the turn. The todo list shows progress; the request is the scope, and finishing the list does not finish the request.
 
-Decisions inside the request are yours: which step comes first, creating branches, worktrees or files in the working folder, installing dependencies, choosing between reasonable implementations, retrying a failed check another way. A document the request points to (a handoff, a plan, a spec) is the request: work its steps in order. A question the request or the files already answer is not a question for the person. If the intent or scope is unclear, progress with the information available, state the assumption you made, and keep working on whatever does not depend on the answer.
+Decisions inside the request are yours: which step comes first, creating branches, worktrees or files in the working folder, installing dependencies, choosing between reasonable implementations, retrying a failed check another way. A document the request points to (a handoff, a plan, a spec) is the request: work its steps in order. A question the request or the files already answer is not a question for the person. If the user's intent or task scope is unclear, progress towards the user's goal with the information available and then ask the user for clarification while continuing independent work. Ask that question with \`ask_user\` after the independent work, not instead of it.
 
 Do not treat an exception to a rule in a local file or skill as automatically needing approval. First decide whether the session already authorizes it and whether the rule applies.
 
-Stop with work still open only for what the person alone can do \u2014 a deploy, a secret, remote data, money, missing access, a product choice the request leaves open, or a fix to a test or error that does not come from this session's work \u2014 and then say exactly what is needed; otherwise the reply ends only when the work-slice guard hands it back or the person interrupts.`;
+Stop with work still open only for what the person alone can do \u2014 a deploy, a login or secret, remote data, money, missing access, a product choice the request leaves open, or a fix to a test or error that does not come from this session's work \u2014 and then give the exact command or screen they must use, not a description of it; otherwise the reply ends only when the work-slice guard hands it back or the person interrupts.`;
 var PERMISSION = `Use your best judgement about when you really need the person's permission, like a competent colleague would. Once evidence in the session supports authorization for a next step, continue without ending the turn to clarify.
 
 Authorization and preferences persist across turns: do not ask again for an action the person already authorized. The person's instruction, stated or implied by the task, takes precedence over guidelines in skills and other files.
@@ -2552,6 +2554,7 @@ ${ROLE_SUBAGENTS}` : ROLE;
   return [
     { id: "role", title: "Role", body: role, budget: 1400, order: ROLE_ORDER },
     { id: "autonomy", title: "Autonomy and persistence", body: AUTONOMY, budget: 2600, order: AUTONOMY_ORDER },
+    { id: "personality", title: "Personality", body: PERSONALITY, budget: 1200, order: PERSONALITY_ORDER },
     { id: "permission", title: "When to ask the person", body: PERMISSION, budget: 1800, order: PERMISSION_ORDER },
     { id: "steering", title: "Working with the person", body: STEERING, budget: 2e3, order: STEERING_ORDER },
     { id: "writing", title: "Writing style", body: WRITING_STYLE, budget: 1900, order: WRITING_ORDER },
@@ -2560,285 +2563,74 @@ ${ROLE_SUBAGENTS}` : ROLE;
 }
 
 // src/prompt/reporting.ts
-var REPORTING_GUIDANCE = `When you finish work, write the final reply for a person who did not watch you work. They have not seen your tool calls, the files you read, or the output you saw. The reply is the whole report: it must stand alone. Reporting is for work that is finished or genuinely blocked. Do not end a turn to report work you can still do.
+var REPORTING_GUIDANCE = `The final answer must always be fully self-contained: users should never need to read earlier commentary updates, since they are collapsed after the final answer is shown to users. In your final answer, focus on the most important information.
 
-### What the reply is for
+Reporting is for work that is finished or genuinely blocked. Do not end a turn to report work you can still do.
 
-The person reads the reply to decide what to do next. Give them, in this order: what happened, what changed, how to try it, and what they should do. Everything else is optional.
+### Technical communication
 
-Write for a competent colleague who was not in the session. Do not assume they know the plan, the files, the commands, or the attempts that failed. If they would have to ask a question to act on the reply, the reply is not finished.
+Use plain language over jargon, and reference technical details only to the degree that it actually helps the conversation. Communicate complex concepts in a clear and cohesive manner. The user should never have to read your writing twice to understand it.
 
-The reply is not a transcript. Leave out what you tried and abandoned, the tool calls, your internal reasoning, and code the person can open. Keep what changes their decision or their next step. A person often reads only the first line and the test block, so both must stand alone.
+Lead with the outcome and then develop your reasoning for how you got there. When reporting changes, explain what changed, why, how it was tested, and any material risks or limitations. Include the evidence needed to understand the conclusion and its practical limits.
 
-### The first line
+Present reasoning and evidence in the order that makes the conclusion easiest to assess, rather than recounting your work chronologically. Summarize routine verification instead of listing every check. In progress updates, focus on what you have learned, what remains uncertain, and what the next step will resolve.
 
-- State the outcome, not the activity. Write "The importer now handles quoted fields; all 12 tests pass", not "I worked on the importer".
-- Say whether the work is done. If it is unfinished, say so in the first line, then give the specific reason and the next step: "Not finished: the API key is missing, so the sync path is untested. Everything else is in place."
-- If the person asked a question, answer it in the first line, then support the answer.
-- No preamble ("Great question", "Let me explain"), no restating the request, no closing recap of what you already said.
+Use tables for mappings or comparisons.
 
-### Choose the shape
+### Headings
 
-| The task was | The shape |
-|---|---|
-| A change to code, files, configuration, a capability, a setting or a document the person will use | Outcome, what changed, how to test, what to do next. These four are required. |
-| An answer or research with no files changed | Outcome, then the findings with sources. Add a test block only if the person can run something. Add a next step only if one follows. |
-| A question | One to three sentences and no headings. |
-| A blocked or unfinished change | First line: unfinished and why. Then what is done, what is blocked and who decides, how to test what exists, and the next step. |
-
-A change means the person can do something different after it. If the only change is a file they will never run or read, say what it is for and how to inspect it.
-
-### What to leave out
-
-- Your narration of the work: which tools you called, which files you opened, which attempt failed first.
-- Code the person can open. Quote a line only when the exact text is the point.
-- Praise, apologies and remarks about the reply itself.
-- Speculative risks with no action. A real risk belongs in the unverified block with a check.
-- The plan and the request restated. The person wrote them.
-
-### Required blocks for a change
-
-#### Outcome
-
-One or two sentences. Done or unfinished, and the effect in plain words. Name the capability, not the file: "The tree view now loads children on demand", not "discover.ts changed".
-
-#### What changed
-
-- Name the relevant paths and say what changed in each and why. Link a file when the person will open it, for example \`src/plugins/install.ts\`.
-- Use a table with the columns File, Change, Why when three or more files changed. Use bullets for one or two.
-- Group related changes. Do not paste diffs, whole functions or file contents the person can open.
-- Mention a deleted, renamed or moved file explicitly, and why.
-- If the change is invisible in the product yet, say that: infrastructure, a migration, a guard, a test seam.
-- If nothing changed, say so plainly and say why the request needed no change.
-
-#### How to test
-
-This block is the one the person will follow. Make it runnable without reading the rest of the reply.
-
-- Number the steps in the order the person performs them.
-- Give the exact command, the exact URL, or the exact UI path. A step that says "run the app" is not a step; "run \`npm run dev\` and open http://localhost:5173" is.
-- Say what the person should see after each step. "The list shows three rows, newest first" is a result; "it works" is not.
-- Say what you already ran and what it returned, so the person does not repeat it.
-- Say which step the person must do that you could not, and why you could not do it.
-- Say what is needed before the test: an account, a key, a fixture, a running service, a browser. If it is missing, give the fallback.
-- If the change has no user-visible effect, write one line: "Nothing to run: the unit tests cover it" or "Nothing to run: the change is in the build, not the product", and name the check that covers it.
-- Keep the steps in the report, not in a separate file.
-
-When several checks share fields, a table is shorter than a list:
-
-    | Check | Command | Expected |
-    |---|---|---|
-    | Unit | \`npm test\` | 41 passed, 0 failed |
-    | Types | \`npm run typecheck\` | no output |
-
-#### What to do next
-
-- State the person's next action, or say "Nothing needed" when the work is complete.
-- If a decision is needed, name the options and your recommendation first, then the choice the person owns.
-- If a follow-up is needed, name who does it and when. Do not assign work to the person without saying why it is theirs.
-- If the next step depends on a missing secret, account, remote data or approval, say exactly what is needed; do not ask for it as a question at the end of the report.
-- Do not use this block to offer optional extras the person did not ask for.
-
-### Optional blocks
-
-Include a block only when it has content. Never add a heading and leave it empty.
+There is no required heading and no preferred set. Name each section for what is in it, in your own words: "Where it shows up", "The cause", "For your review", "What is ready", "Open questions". A short reply needs no headings. Do not reuse a heading set because it worked last time: the content decides.
 
-#### Beyond the request
+### Shape by work
 
-When you did something the request did not name, list each piece and why the work needed it. Examples: a test that would have caught the bug, a fix to the adjacent broken call, a doc line that would otherwise be wrong. This block makes the extra work auditable; it is not a place to list routine steps.
-
-#### Departures from the plan
-
-When you departed from a plan, a handoff or the steps the request gave, say what you did instead and why, and what effect it has. This includes a skipped step, a reordered step, a replaced tool, a narrower scope or a wider one. Do not hide a departure inside the summary.
-
-#### Unverified or needs a person
-
-When a concrete check requires a person because you could not perform or observe it, say what is unverified, why you could not check it, and the exact check to make. Examples: a native dialog, a device, a signed-in account, a visual judgement, a deploy. Use this block for a real check, not for generic risk. If you ran the check, report the result instead; do not call it unverified.
-
-#### Open questions
-
-Only when a question blocks a decision the person must make. State the question, the options and your recommendation. Do not end the report with an open-ended invitation to ask more.
-
-### Headings are yours
-
-Use headings that name the content. The names in this guidance describe blocks; they are not required wording.
-
-- "How to test", "Test it", "Try it", "Verify" and "Test steps" all name the same block.
-- "What changed", "Changes", "What I changed" and "Files" all name the same block.
-- "What to do next", "Next step" and "Over to you" all name the same block.
-- Order the blocks: outcome, changes, test, next, then the optional blocks. Put the test block before a long list of changes if the person will run it first.
-- Do not use a heading that says nothing: "Summary", "Notes", "Worth a look", "Additional information". A heading must tell the reader what they will find.
-- No fixed heading list is required. The requirement is the information, not the label. A short change may need only two headings; a large one may use six.
-- If a block is one sentence, a bold lead-in is enough; a heading is not required.
-
-### Lists and tables
-
-- Bullets for parallel items: files, options, checks.
-- Numbered lists for anything the person performs in order: test steps, next steps, a migration.
-- A Markdown table when several items share fields: File | Change | Why, Check | Command | Result, Option | Cost | Recommendation.
-- Prose for a single point that needs explanation. Do not wrap one sentence in a table.
-- Keep a bullet to one line where possible. If it needs a paragraph, use a paragraph.
+| The work | What the reader needs |
+|---|---|
+| A code change | outcome, what changed and why, how it was tested, risks |
+| A document or copy | what changed in the text, where to read it |
+| An answer or research | the answer, then the evidence and its limits |
+| A diagnosis | the cause, the fix, what to watch for |
+| A publish or release | what is ready, what to review, the risks |
+| Config or operations | what changed where, the rollback, who runs it |
 
 ### Length
 
-- A change: about 20 to 60 lines. A large change may need more, but the outcome, the test block and the next step come first and stay short.
-- A question: one to three sentences.
-- Research: as long as the evidence needs. Do not pad, and do not repeat the sources in the answer and in a list.
-- A blocked task: as long as the person needs to understand the block and act; usually under 30 lines.
-- Never repeat the request, the plan or the previous message to fill space. The person can see them.
-
-For a long command output or log, give the first useful line, the last line, and the path to the full output. Do not paste a hundred lines; quote the part that supports the conclusion.
-
-### Honesty
-
-- Name only checks you actually ran, with their results. "All 12 tests pass" without the command or the count is a claim, not a report.
-- If a check failed, say so, give the failing output or its first useful lines, and say what it means for the change.
-- If you did not run a check, say "not run" and why. Do not imply coverage you do not have.
-- If you could not verify something, put it in the unverified block with the exact check the person should make.
-- If the work is partial, say what is safe to use and what is not.
-- Do not describe a file as working because it compiles. Say what you observed.
-
-A claim becomes a report when it carries its evidence:
-
-    | Claim | What makes it a report |
-    |---|---|
-    | "All tests pass" | \`npm test\`: 41 passed, 0 failed |
-    | "The endpoint works" | \`curl\` returned 200 with the expected body |
-    | "The page looks right" | not a report; name the screen, size and what to look for |
+Scale detail to complexity: a simple change usually needs one or two sentences plus the validation, and a larger change needs the reasoning, the evidence and the risks. Research is as long as the evidence needs. Never repeat the request, the plan or the previous message to fill space.
 
-### Tone
+### Prose and lists
 
-Write directly and concretely. No apologies, no self-congratulation, no filler. Technical detail belongs in the reply when it helps the person act; leave out the reasoning that only mattered while you worked. If the person's language is not English, reply in their language; this guidance describes the shape, not the language.
-
-### Anti-patterns
-
-| Do not | Do instead |
-|---|---|
-| Open with "I've implemented..." and no outcome | Say what now works, in the first line |
-| Restate the request before the answer | Drop the restatement; answer first |
-| "Worth a look" or "Notes" with no action | Name the thing and the action, or drop it |
-| "All tests pass" with no command or count | Give the command, the count and the result |
-| No test step for a change | Add numbered steps, or one line saying nothing to run and why |
-| No next step | Say "Nothing needed", or name the person's action |
-| A departure hidden in the middle | Give it its own block with the reason |
-| A wall of prose for a multi-file change | Use a table and bullets |
-| A long report for a one-line question | One to three sentences |
-| "If you want, I can..." as the ending | Only suggest a follow-up that builds on the request; otherwise stop |
+Write in connected prose. Use lists only when the information is genuinely parallel, sequential, or easier to compare, and avoid nested lists unless the hierarchy cannot be expressed clearly in prose. Use a table when several items share fields.
 
 ### Examples
 
-These examples show the shape, not the words. Copy the structure and the level of detail, then write for the task in front of you.
-
-#### Example 1 \u2014 a small change
-
-    The settings page now remembers the last selected tab, and the choice survives a reload. Two
-    tests cover it and the full suite passes.
-
-    ## What changed
-
-    - \`src/settings/tabs.ts\` stores the tab in local storage and restores it on mount.
-    - \`src/settings/tabs.test.ts\` covers the restore and the fallback when storage is empty.
-
-    ## How to test
-
-    1. Run \`npm run dev\` and open http://localhost:5173/settings.
-    2. Select the "Billing" tab, then reload the page.
-    3. The Billing tab is selected again. With storage cleared, the page falls back to "General".
-
-    I ran \`npm test\`: 41 passed, including the new tests. The reload itself is yours to check; the
-    storage path is covered by the unit test.
-
-    Nothing needed next: the change is complete.
-
-#### Example 2 \u2014 a multi-file change with extra work
-
-    The export job now retries a failed upload twice and records the last error. The retry path is
-    covered by a new test; the full suite passes.
-
-    ## What changed
-
-    | File | Change | Why |
-    |---|---|---|
-    | \`src/export/retry.ts\` | Retries an upload twice with a short backoff | A flaky network no longer fails the whole export |
-    | \`src/export/report.ts\` | Stores the last error on the job | The next attempt can show what went wrong |
-    | \`src/export/retry.test.ts\` | New tests for success, retry and give-up | The retry path had no coverage |
-
-    ## How to test
-
-    1. Run \`npm run test:export\`. Expect all tests to pass, including the three retry cases.
-    2. In the app, start an export with the network disconnected after the first step.
-    3. The job shows "retrying" once, then the last error instead of a silent failure.
+These examples show the shape, not the words.
 
-    I ran \`npm run test:export\`: 18 passed. I did not test the disconnected-network case in the app;
-    that is the manual step above.
+#### Example 1 \u2014 a screen change
 
-    ## Beyond the request
+    The settings page now remembers the last selected tab, and the choice survives a reload.
 
-    I added the error field to the job record. The retry alone would have hidden the cause, and the
-    field is what the next attempt reads.
+    \`npm test\`: 12 passed, including the two new tab tests. I did not open it in a browser, so the
+    visual result is unverified.
 
-    Nothing needed next.
+    Changed \`src/settings/tabs.ts\` to store the tab in local storage and restore it on mount; a
+    missing value falls back to "General". Risk: a key left by an older build is ignored, not
+    migrated.
 
-#### Example 3 \u2014 a blocked or unfinished change
+#### Example 2 \u2014 a blocked publish
 
-    Not finished: the sync path is implemented and tested, but the API key is missing, so I could not
-    run it against the live service.
+    The release notes for 1.4.0 are written. The tag and the publish did not run: this shell has no
+    authenticated GitHub CLI.
 
-    ## What is done
-
-    - \`src/sync/client.ts\` sends the new payload and retries once on a 5xx.
-    - \`src/sync/client.test.ts\` covers the payload and the retry; 9 tests pass.
-
-    ## How to test what exists
-
-    1. Run \`npm test -- sync\`. Expect 9 passing tests.
-    2. Add \`SYNC_API_KEY\` to \`.env\`, then run \`npm run sync:check\`.
-    3. Expect "sync ok" and one record in the staging table.
-
-    I could not run step 2 or 3: the key is not in this environment, and I did not have the
-    account. Do not use this against production until step 3 passes.
-
-    ## What to do next
-
-    Add \`SYNC_API_KEY\` to \`.env.local\` and run \`npm run sync:check\`. If it fails on auth, the
-    key belongs to the staging workspace, not the sandbox one. Nothing else is blocked.
-
-#### Example 4 \u2014 a research answer
-
-    The harness already reads Claude-layout skills from a package once its manifest declares them,
-    but it does not scan \`.claude/skills\` directly.
-
-    ## What I found
-
-    - The resolver scans \`.pi/skills\`, \`.agents/skills\` and package \`skills/\` folders; it never
-      reads a \`.claude\` folder.
-    - A package can declare its skill folder in \`.claude-plugin/plugin.json\`; the harness reads
-      that path and adds the folder as a package skill.
-
-    Sources: \`src/plugins/discover.ts\` (the resolver) and \`src/plugins/manifest.ts\` (the
-    manifest).
-
-    Next step: if you want a pasted repository to contribute its skills, install the repository
-    itself rather than a page URL.
-
-#### Example 5 \u2014 a one-line question
-
-    It reads both: \`plugin.json\` first, then \`.claude-plugin/plugin.json\`, and the first one with
-    a \`skills\` field wins.
+    Run \`gh auth login --hostname github.com\` in the project folder; then I can tag \`v1.4.0\` and
+    push. Nothing has been published.
 
 ### Before you send
 
 - The first line says what happened and whether it is done.
-- A change has a what-changed block, a how-to-test block and a what-to-do-next block.
-- Paths are named; a table holds three or more files.
-- Every check you name was actually run, with its result.
-- A departure or extra piece of work has its own block.
+- Every claim carries the evidence that supports it.
+- The headings name what is under them.
 - Nothing is repeated from the request or the plan.
-- The headings fit the content; none is empty.
-- A person can act from the test block alone.
-- Nothing is claimed that the record does not support.
 `;
-var REPORTING_BUDGET = 18e3;
+var REPORTING_BUDGET = 12e3;
 
 // src/prompt/compile.ts
 var IDENTITY_BUDGET = 1e3;
@@ -2852,7 +2644,7 @@ var VARIANT_BUDGET = 3e4;
 var NOTES_LISTED = 25;
 var APPROVAL_GUIDANCE = "Approvals: when a call needs a person, the Harness pauses that exact call and shows them Allow and Deny. Never ask for permission in a message, never end your turn to wait for an answer, and never call a task blocked on approval before trying: a denial arrives as the tool result, and you continue from it.";
 var SECTION_ORDER = { harnessIdentity: 5, system: 25, sessionState: 30, guardrails: 40, memory: 45, references: 50, requiredSkills: 52, subagents: 64, scripts: 66, wiki: 80, tools: 90, reporting: 95 };
-var STOP_GATE_GUIDANCE = "A reply that ends while its todo list has open items is sent back to you, so keep working until the request is done. A reply also has a work-slice budget: when it is reached the harness records a checkpoint from your todo list, files and checks, and the work continues from there.";
+var WORK_SLICE_GUIDANCE = "A reply also has a work-slice budget: when it is reached the harness records a checkpoint from your todo list, files and checks, and the work continues from there.";
 var HISTORY_GROUP = ["history_search", "history_read", "trajectory_search", "trajectory_read"];
 var WIKI_GROUP = ["wiki_search", "wiki_read", "wiki_list", "wiki_write"];
 var NATIVE_GROUP = ["read", "grep", "find", "ls", "edit", "write", "bash"];
@@ -2947,7 +2739,8 @@ function toolGroups(context, launch, dataRoot) {
   const wikiTools = WIKI_GROUP.filter((name) => name !== "wiki_write" || enabled.includes(name));
   const readGuidance = `Read-only file tools accept absolute paths and paths beginning with ~ anywhere this process has operating-system read access. The working folder is a default location, not a read boundary.${dataRoot ? ` The Harness data root is ${dataRoot}.` : ""}`;
   const writeGuidance = "Keep native file writes and Bash filesystem effects inside the active project workspace, where they run without asking. An outside file target is allowed too: call the tool and the Harness pauses that one call until the person clicks Allow or Deny, so nothing outside changes first. Remembered tool grants do not answer an outside target; only the explicit Full Permission switch answers it for the run. Bash, including an initial ! command, may read as before but writes are sandboxed to the workspace unless that switch is on. Keep task outputs in the project, following an existing artifacts/ or outputs/ convention when present.";
-  const nativeGuidance = `Files and shell: ${readGuidance} ${writeGuidance} Edits and commands still pass through the Harness gate.`;
+  const workRules = "Work rules: search with rg before slower tools. Do not chain commands with separators for decoration. Treat shell text as code: quote it properly, never interpolate unescaped values, and never risk exposing secrets in output. Do not reuse $HOME or other common variable names for task values. Avoid blocking sleeps that keep you from reporting back. Do not write tests for reversible, low-impact changes or that mirror the implementation; if you verify with tests, make them meaningful and necessary. Run the tests appropriate to the change; once they pass, broaden or repeat testing only when new changes, failures or unresolved concerns justify it.";
+  const nativeGuidance = `Files and shell: ${readGuidance} ${writeGuidance} Edits and commands still pass through the Harness gate. ${workRules}`;
   const groups = [
     {
       group: "History",
@@ -2959,7 +2752,7 @@ function toolGroups(context, launch, dataRoot) {
       group: "Wiki",
       tools: [...wikiTools, "skill_load"],
       order: GROUP_ORDER.Wiki,
-      guidance: `Wiki: wiki_search, wiki_read and wiki_list read project notes${wikiTools.includes("wiki_write") ? "; wiki_write saves one" : ""}. skill_load loads one of your skills by name.`
+      guidance: `Wiki: wiki_search, wiki_read and wiki_list read project notes${wikiTools.includes("wiki_write") ? "; wiki_write saves one" : ""}. skill_load loads one of your skills by name. Skills: a skill is a set of instructions provided through a SKILL.md. The user's instructions take precedence over a skill. The first time you apply a skill, say so in your reply. If the user names a skill ($SkillName or plain text), add it to your plan; if it is missing and needed, stop and tell them why. Read it with skill_load before applying it. Plugins are bundles of skills, tools and apps: use their underlying capabilities, and if a named plugin has nothing relevant, say so briefly and continue with the best fallback.`
     },
     { group: "Native", tools: native, order: GROUP_ORDER.Native, guidance: nativeGuidance },
     // Web, browser and computer tools: the harness's own, and their results are untrusted (world/untrusted.ts).
@@ -2968,8 +2761,8 @@ function toolGroups(context, launch, dataRoot) {
   ];
   const progressTools = [TODO_WRITE].filter((name) => enabled.includes(name));
   if (progressTools.length) {
-    const gate = launch.standard ? STOP_GATE_GUIDANCE : "";
-    groups.push({ group: "Progress", tools: progressTools, order: 87, guidance: `Progress: ${[TODO_GUIDANCE, gate].filter(Boolean).join(" ")}` });
+    const slice = launch.standard ? WORK_SLICE_GUIDANCE : "";
+    groups.push({ group: "Progress", tools: progressTools, order: 87, guidance: `Progress: ${[TODO_GUIDANCE, slice].filter(Boolean).join(" ")}` });
   }
   if (enabled.includes(SESSION_NAME)) {
     groups.push({
@@ -3131,7 +2924,7 @@ ${variant.toolGuidance.trim()}
   const built = [
     {
       order: SECTION_ORDER.harnessIdentity,
-      section: section("harness-identity", "Harness identity", `You are an AI agent running in ${env.productName}.`, IDENTITY_BUDGET, "", [])
+      section: section("harness-identity", "Harness identity", `You are an AI agent running in ${env.productName}${launch.model ? `, based on ${launch.model}` : ""}. You and the user share one workspace, and your job is to collaborate with them until their intended goal is completely handled.`, IDENTITY_BUDGET, "", [])
     },
     ...(variant?.sections ?? []).map((entry2) => ({ order: entry2.order, section: section(entry2.id, entry2.title, entry2.body, VARIANT_BUDGET, "", variantSource) })),
     { order: SECTION_ORDER.sessionState, section: sessionStateSection(launch.sessionState, launch.tools ?? []) },
@@ -7653,7 +7446,7 @@ function askUserTool(run2) {
   return {
     name: ASK_USER,
     label: "Ask the user",
-    description: "Ask the user one to five related questions in one request and wait until they answer the batch. Give each question a concise 1\u20132 word label and aim to keep each question to 25 words or fewer. Every question must offer 1\u20136 short choices, each with a helpful description of 25 words or fewer, and at least one choice must be marked recommended: true. Recommendations are visual only: they never preselect an answer, and submitted choices keep their original labels. Mark at most one recommended choice for a single-choice question, or several when multiSelect is true. Every question also includes a free-text \u201CSomething else\u201D answer. Set multiSelect when several can apply. When a UI diagram helps compare choices, set uiSketch: true and give every choice a detailed, bounded ASCII wireframe. Use ASCII tables and panel borders to show the affected element with relevant neighboring UI, readable labels and spacing. Keep each panel\u2019s outer `+` corners in fixed columns, include side edges at those same columns on every content row, and run horizontal borders corner to corner; if a title sits in a top border, leave at least two dashes on both sides. Keep framing consistent across alternatives and concentrate detail on what changes. Do not substitute a symbolic logo or one-line illustration. The preview supplies its outer border; draw internal borders only for actual UI panels. Use it when you need a decision the request and the files do not answer, not for small talk and never to ask permission for work inside the request. If no answer arrives, continue with your best judgment instead of asking again or treating the turn as blocked.",
+    description: "Ask the user one to five related questions in one request and wait until they answer the batch. Give each question a concise 1\u20132 word label and aim to keep each question to 25 words or fewer. Every question must offer 1\u20136 short choices, each with a helpful description of 25 words or fewer, and at least one choice must be marked recommended: true. Recommendations are visual only: they never preselect an answer, and submitted choices keep their original labels. Mark at most one recommended choice for a single-choice question, or several when multiSelect is true. Every question also includes a free-text \u201CSomething else\u201D answer. Set multiSelect when several can apply. When a UI diagram helps compare choices, set uiSketch: true and give every choice a detailed, bounded ASCII wireframe. Use ASCII tables and panel borders to show the affected element with relevant neighboring UI, readable labels and spacing. Keep each panel\u2019s outer `+` corners in fixed columns, include side edges at those same columns on every content row, and run horizontal borders corner to corner; if a title sits in a top border, leave at least two dashes on both sides. Keep framing consistent across alternatives and concentrate detail on what changes. Do not substitute a symbolic logo or one-line illustration. The preview supplies its outer border; draw internal borders only for actual UI panels. Use it when you need a decision the request and the files do not answer, not for small talk and never to ask permission for work inside the request. If no answer arrives, continue with your best judgment instead of asking again or treating the turn as blocked. Never use it to ask for a login, a secret or a credential: give the exact command in the reply instead.",
     parameters: (Type3) => Type3.Object({
       questions: Type3.Array(Type3.Object({
         summary: Type3.String({ description: "A concise label of one or two words" }),
@@ -21499,7 +21292,7 @@ ${formatBashCommandForApproval(command)}`,
       const profiles = this.options.subagents && input.subagents !== null ? profileSection(root, input.cwd, variant?.dir ?? null, false, void 0, loading?.profilePaths ?? []) : null;
       const launchSections = profiles ? [...(input.launch?.sections ?? []).filter((section2) => section2.id !== profiles.id), profiles] : input.launch?.sections;
       const standard = input.launch?.standard === null ? null : input.launch?.standard ?? { cwd: input.cwd };
-      const pack = compile(env, caller, { ...input.launch, standard, sections: launchSections, tools: launchTools }, variant && profiles ? { ...variant, sections: variant.sections.filter((section2) => section2.id !== profiles.id) } : variant);
+      const pack = compile(env, caller, { ...input.launch, model: input.model ?? input.launch?.model ?? null, standard, sections: launchSections, tools: launchTools }, variant && profiles ? { ...variant, sections: variant.sections.filter((section2) => section2.id !== profiles.id) } : variant);
       record(root, pack);
       mkdirSync23(this.historyDir(input), { recursive: true });
       saveForSession(input.sessionFolder, pack);
@@ -22736,67 +22529,6 @@ function imagePruning() {
   };
 }
 
-// src/sessions/compactionCheckpoint.ts
-var COMPACTION_CHECKPOINT_EXTENSION = "compaction-checkpoint";
-function validatedTodo(value) {
-  if (!Array.isArray(value) || value.length > MAX_TODO_ITEMS) return null;
-  const items = [];
-  for (const valueItem of value) {
-    const item = valueItem;
-    const parsed = todoItemSchema.safeParse({
-      text: typeof item?.text === "string" ? item.text.trim() : item?.text,
-      status: item?.status
-    });
-    if (!parsed.success) return null;
-    items.push(parsed.data);
-  }
-  return items;
-}
-function compactionCheckpoint(options2 = {}) {
-  return (pi) => {
-    let goal = "";
-    let todo = validatedTodo(options2.initialTodo ?? []) ?? [];
-    let baseline;
-    let checkpoint;
-    const reset = (prompt = "") => {
-      goal = prompt;
-      todo = validatedTodo(options2.initialTodo ?? []) ?? [];
-      baseline = void 0;
-      checkpoint = void 0;
-    };
-    pi.on("before_agent_start", (event) => {
-      if (event.messageType !== "user") return;
-      reset(event.prompt);
-    });
-    pi.on("tool_result", (event) => {
-      if (event.toolName !== TODO_WRITE || event.isError) return;
-      const items = validatedTodo(event.input.items);
-      if (items) todo = items;
-    });
-    pi.on("context", (event) => {
-      const index = event.messages.findLastIndex((message4) => message4.role === "compactionSummary");
-      const summary4 = index >= 0 ? event.messages[index] : void 0;
-      const key = summary4 ? `${summary4.timestamp}:${summary4.tokensBefore}` : null;
-      if (!baseline) {
-        baseline = { key };
-        return;
-      }
-      if (!key || key === baseline.key) return;
-      if (checkpoint?.key !== key) {
-        const content = renderCompactionCheckpoint({ goal, todo, planInstructions: options2.planInstructions?.() ?? null });
-        checkpoint = {
-          key,
-          message: content ? { role: "custom", customType: COMPACTION_CHECKPOINT_EXTENSION, content, display: false, timestamp: Date.now() } : null
-        };
-      }
-      if (!checkpoint.message) return;
-      return { messages: [...event.messages.slice(0, index + 1), checkpoint.message, ...event.messages.slice(index + 1)] };
-    });
-    pi.on("agent_settled", () => reset());
-    pi.on("session_tree", () => reset());
-  };
-}
-
 // src/sessions/completionCheck.ts
 var MAX_CHECK_TRANSCRIPT = 24e3;
 var MAX_TOOL_RESULT = 600;
@@ -22910,105 +22642,6 @@ async function runCompletionCheck(ask, input, options2 = {}) {
 function answerText(message4) {
   return textOf(message4?.content);
 }
-function launchSwitchOff(name) {
-  const value = process.env[name]?.trim().toLowerCase();
-  return value === "off" || value === "0" || value === "false";
-}
-
-// src/sessions/stopGate.ts
-var STOP_GATE_EXTENSION = "stop-gate";
-var STOP_GATE_CUSTOM_TYPE = "xingular-stop-gate";
-var MAX_STOP_GATE_NUDGES = 3;
-var BOOKKEEPING_TOOLS = /* @__PURE__ */ new Set([TODO_WRITE, "session_name"]);
-function createStopGateState(initialTodo = []) {
-  return { todo: validatedTodo(initialTodo) ?? [], request: "", nudges: 0, callsSinceNudge: 0, callsInReply: 0 };
-}
-function resetStopGateState(state, initialTodo = [], request2 = "") {
-  state.todo = validatedTodo(initialTodo) ?? [];
-  state.request = request2;
-  state.nudges = 0;
-  state.callsSinceNudge = 0;
-  state.callsInReply = 0;
-}
-function openItems(todo) {
-  return todo.filter((item) => item.status !== "completed");
-}
-function stopOutcome(state, goal) {
-  const open3 = openItems(state.todo);
-  if (goal?.status === "blocked") return { code: "needs_person", reason: goal.lastReason || "The goal is blocked.", open: open3 };
-  if (goal && (goal.status === "budget_limited" || goal.status === "usage_limited" || goal.status === "paused")) {
-    return { code: "unfinished", reason: goal.lastReason || `The goal is ${goal.status.replace("_", " ")}.`, open: open3 };
-  }
-  if (open3.length) return { code: "unfinished", reason: "", open: open3 };
-  return null;
-}
-function handoffFields(state, goal) {
-  const todo = state?.todo ?? [];
-  const next = openItems(todo)[0]?.text || "";
-  const blocked = goal?.status === "blocked" ? (goal.lastReason || "The goal is blocked.").slice(0, 500) : "";
-  return {
-    done: todo.filter((item) => item.status === "completed").slice(0, MAX_CHECKPOINT_DONE).map((item) => ({ item: item.text.slice(0, 300), evidence: [] })),
-    next: next.slice(0, 500),
-    ...blocked ? { blocked } : {}
-  };
-}
-var stopCheckpointReason = (outcome) => outcome.code === "needs_person" ? "requested" : "stuck";
-function stopSummary(outcome) {
-  if (outcome.code === "needs_person") return `The reply stopped for the person: ${outcome.reason}`.slice(0, 1200);
-  if (outcome.reason) return `The reply ended with work left: ${outcome.reason}`.slice(0, 1200);
-  return `The reply ended with ${outcome.open.length} open todo item${outcome.open.length === 1 ? "" : "s"}.`;
-}
-function nudgeText(count, max, open3) {
-  const list7 = open3.slice(0, 12).map((item) => `- ${item.text}`).join("\n");
-  const more = open3.length > 12 ? `
-- \u2026and ${open3.length - 12} more` : "";
-  return [
-    `Harness stop gate (${count}/${max}): your reply ended with ${open3.length} open todo item${open3.length === 1 ? "" : "s"}:`,
-    `${list7}${more}`,
-    "Continue with the next open item now. Mark an item completed only after it is done and checked.",
-    "The list shows progress; it is not the limit of the work. If the request needs more than the list says, add it and do it.",
-    "Decisions inside the request are yours. Stop only for something only the person can do (a deploy, a secret, remote data, money, missing access), and then say exactly what it is."
-  ].join("\n");
-}
-function stopGateNotice(event) {
-  return `Stop gate ${event.count}: the reply ended with ${event.open.length} open todo item${event.open.length === 1 ? "" : "s"}; continuing.`;
-}
-function stopGate(options2) {
-  const { state } = options2;
-  const max = options2.max ?? MAX_STOP_GATE_NUDGES;
-  return (pi) => {
-    pi.on("before_agent_start", (event) => {
-      if (event.messageType !== void 0 && event.messageType !== "user") return;
-      resetStopGateState(state, options2.initialTodo, options2.request?.() || (typeof event.prompt === "string" ? event.prompt : ""));
-    });
-    pi.on("tool_call", (event) => {
-      if (BOOKKEEPING_TOOLS.has(event.toolName)) return;
-      state.callsSinceNudge += 1;
-      state.callsInReply += 1;
-    });
-    pi.on("tool_result", (event) => {
-      if (event.toolName !== TODO_WRITE || event.isError) return;
-      const items = validatedTodo(event.input?.items);
-      if (items) state.todo = items;
-    });
-    pi.on("agent_before_settle", (event, ctx) => {
-      if (event.outcome !== "completed" || event.continue || ctx?.signal?.aborted) return;
-      if (options2.active && !options2.active()) return;
-      if (options2.sliceEnded?.() || options2.failed?.()) return;
-      if (state.nudges >= max) return;
-      if (state.nudges > 0 && state.callsSinceNudge === 0) return;
-      const open3 = openItems(state.todo);
-      if (!open3.length) return;
-      state.nudges += 1;
-      state.callsSinceNudge = 0;
-      options2.onEvent?.({ kind: "todo", count: state.nudges, open: open3 });
-      return {
-        entries: [...event.entries, { type: "custom_message", customType: STOP_GATE_CUSTOM_TYPE, content: nudgeText(state.nudges, max, open3), display: true }],
-        continue: true
-      };
-    });
-  };
-}
 function sessionCheckModel(ctx) {
   const session = ctx ?? {};
   const model = session.model;
@@ -23023,6 +22656,10 @@ function sessionCheckModel(ctx) {
     return { text: answerText(message4), message: message4 };
   };
 }
+function launchSwitchOff(name) {
+  const value = process.env[name]?.trim().toLowerCase();
+  return value === "off" || value === "0" || value === "false";
+}
 
 // src/sessions/goalLoop.ts
 var GOAL_EXTENSION = "goal";
@@ -23219,6 +22856,67 @@ function latestSessionName(historyFile) {
   return name;
 }
 
+// src/sessions/compactionCheckpoint.ts
+var COMPACTION_CHECKPOINT_EXTENSION = "compaction-checkpoint";
+function validatedTodo(value) {
+  if (!Array.isArray(value) || value.length > MAX_TODO_ITEMS) return null;
+  const items = [];
+  for (const valueItem of value) {
+    const item = valueItem;
+    const parsed = todoItemSchema.safeParse({
+      text: typeof item?.text === "string" ? item.text.trim() : item?.text,
+      status: item?.status
+    });
+    if (!parsed.success) return null;
+    items.push(parsed.data);
+  }
+  return items;
+}
+function compactionCheckpoint(options2 = {}) {
+  return (pi) => {
+    let goal = "";
+    let todo = validatedTodo(options2.initialTodo ?? []) ?? [];
+    let baseline;
+    let checkpoint;
+    const reset = (prompt = "") => {
+      goal = prompt;
+      todo = validatedTodo(options2.initialTodo ?? []) ?? [];
+      baseline = void 0;
+      checkpoint = void 0;
+    };
+    pi.on("before_agent_start", (event) => {
+      if (event.messageType !== "user") return;
+      reset(event.prompt);
+    });
+    pi.on("tool_result", (event) => {
+      if (event.toolName !== TODO_WRITE || event.isError) return;
+      const items = validatedTodo(event.input.items);
+      if (items) todo = items;
+    });
+    pi.on("context", (event) => {
+      const index = event.messages.findLastIndex((message4) => message4.role === "compactionSummary");
+      const summary4 = index >= 0 ? event.messages[index] : void 0;
+      const key = summary4 ? `${summary4.timestamp}:${summary4.tokensBefore}` : null;
+      if (!baseline) {
+        baseline = { key };
+        return;
+      }
+      if (!key || key === baseline.key) return;
+      if (checkpoint?.key !== key) {
+        const content = renderCompactionCheckpoint({ goal, todo, planInstructions: options2.planInstructions?.() ?? null });
+        checkpoint = {
+          key,
+          message: content ? { role: "custom", customType: COMPACTION_CHECKPOINT_EXTENSION, content, display: false, timestamp: Date.now() } : null
+        };
+      }
+      if (!checkpoint.message) return;
+      return { messages: [...event.messages.slice(0, index + 1), checkpoint.message, ...event.messages.slice(index + 1)] };
+    });
+    pi.on("agent_settled", () => reset());
+    pi.on("session_tree", () => reset());
+  };
+}
+
 // src/sessions/workSlice.ts
 var WORK_SLICE_EXTENSION = "work-slice";
 var DEFAULT_SLICE_POLICY = {
@@ -23770,6 +23468,34 @@ function planSection(plan, historyFile, researchSubagent = false) {
   return delivered?.some((entry2) => entry2.id === PLAN_SECTION_ID) ? { id: PLAN_SECTION_ID, title: "Plan mode", body: null, budget: 8e3, order: PLAN_SECTION_ORDER, dynamic: true } : null;
 }
 
+// src/sessions/goalStop.ts
+function openItems(todo) {
+  return todo.filter((item) => item.status !== "completed");
+}
+function goalStopOutcome(todo, goal) {
+  const open3 = openItems(todo);
+  if (goal?.status === "blocked") return { code: "needs_person", reason: goal.lastReason || "The goal is blocked.", open: open3 };
+  if (goal && (goal.status === "budget_limited" || goal.status === "usage_limited" || goal.status === "paused")) {
+    return { code: "unfinished", reason: goal.lastReason || `The goal is ${goal.status.replace("_", " ")}.`, open: open3 };
+  }
+  return null;
+}
+function handoffFields(todo, goal) {
+  const next = openItems(todo)[0]?.text || "";
+  const blocked = goal?.status === "blocked" ? (goal.lastReason || "The goal is blocked.").slice(0, 500) : "";
+  return {
+    done: todo.filter((item) => item.status === "completed").slice(0, MAX_CHECKPOINT_DONE).map((item) => ({ item: item.text.slice(0, 300), evidence: [] })),
+    next: next.slice(0, 500),
+    ...blocked ? { blocked } : {}
+  };
+}
+var stopCheckpointReason = (outcome) => outcome.code === "needs_person" ? "requested" : "stuck";
+function stopSummary(outcome) {
+  if (outcome.code === "needs_person") return `The reply stopped for the person: ${outcome.reason}`.slice(0, 1200);
+  if (outcome.reason) return `The reply ended with work left: ${outcome.reason}`.slice(0, 1200);
+  return `The reply ended with ${outcome.open.length} open todo item${outcome.open.length === 1 ? "" : "s"}.`;
+}
+
 // src/sessions/reasoningSummaries.ts
 var MAX_REASONING_SUMMARY_CHARS = 4e3;
 var REASONING_SUMMARY_APIS = /* @__PURE__ */ new Set([
@@ -24235,10 +23961,10 @@ var lastLine = (text10) => {
   const lines2 = text10.split("\n").map((line2) => line2.trim()).filter(Boolean);
   return (lines2.at(-1) ?? "").slice(0, 300);
 };
-function derivedCheckpoint(ledger, slice, reason, fallback, gate, goal) {
+function derivedCheckpoint(ledger, slice, reason, fallback, goal) {
   return {
     summary: ledger.lastText.trim().slice(0, MAX_CHECKPOINT_SUMMARY) || fallback,
-    ...handoffFields(gate, goal),
+    ...handoffFields(ledger.todo, goal),
     files: [...ledger.files].slice(-MAX_CHECKPOINT_FILES).map(([path4, why]) => ({ path: path4.slice(0, 300), why: why.slice(0, 200) })),
     checks: ledger.checks.slice(-MAX_CHECKPOINT_CHECKS),
     decisions: [],
@@ -24261,7 +23987,7 @@ async function runTurn(run2, session, params) {
   let costReported = false;
   const toolStartedAt = /* @__PURE__ */ new Map();
   const slice = params.slice?.state ?? null;
-  const ledger = { files: /* @__PURE__ */ new Map(), checks: [], lastText: "" };
+  const ledger = { files: /* @__PURE__ */ new Map(), checks: [], lastText: "", todo: [] };
   const bashCommands = /* @__PURE__ */ new Map();
   const heartbeat = slice ? setInterval(() => {
     run2.emit("heartbeat", {
@@ -24459,6 +24185,10 @@ async function runTurn(run2, session, params) {
           const command = tool.args && typeof tool.args === "object" ? tool.args.command : null;
           if (typeof command === "string") bashCommands.set(tool.toolCallId, command);
         }
+        if (tool.toolName === TODO_WRITE) {
+          const items = validatedTodo(tool.args && typeof tool.args === "object" ? tool.args.items : void 0);
+          if (items) ledger.todo = items;
+        }
         break;
       }
       case "tool_execution_end": {
@@ -24633,14 +24363,14 @@ ${initialBashInstruction}` : prompt;
       }
     }
     if (slice?.endedBy && !aborted && !lastError) {
-      run2.emit("checkpoint", derivedCheckpoint(ledger, slice.slice, derivedReason(slice.endedBy), `The reply stopped after ${slice.steps} steps at its work-slice boundary.`, params.stopGate, params.goal?.controller.get()));
+      run2.emit("checkpoint", derivedCheckpoint(ledger, slice.slice, derivedReason(slice.endedBy), `The reply stopped after ${slice.steps} steps at its work-slice boundary.`, params.goal?.controller.get()));
       run2.finish("interrupted", void 0, "slice_complete", slice.endedBy === "budget" ? "slice_budget" : "compaction_thrash");
       return;
     }
     const goalState = params.goal?.controller.get() ?? null;
-    const stop = (params.stopGate || goalState) && !aborted && !lastError ? stopOutcome(params.stopGate ?? createStopGateState(), goalState) : null;
+    const stop = goalState && !aborted && !lastError ? goalStopOutcome(ledger.todo, goalState) : null;
     if (stop) {
-      run2.emit("checkpoint", derivedCheckpoint(ledger, slice?.slice ?? 1, stopCheckpointReason(stop), stopSummary(stop), params.stopGate, goalState));
+      run2.emit("checkpoint", derivedCheckpoint(ledger, slice?.slice ?? 1, stopCheckpointReason(stop), stopSummary(stop), goalState));
       run2.finish("interrupted", void 0, stop.code, stop.code);
       return;
     }
@@ -24879,21 +24609,6 @@ function checkCommand(command, historyFile, input) {
   }
 }
 var CONTINUE_TEXT = "Continue from where you stopped.";
-function requestOfChain(root, runId) {
-  const seen = /* @__PURE__ */ new Set();
-  for (let current2 = runId; current2 && !seen.has(current2); ) {
-    seen.add(current2);
-    let record3;
-    try {
-      record3 = loadRun2(root, current2);
-    } catch {
-      return null;
-    }
-    if (record3.goal && record3.goal.trim() !== CONTINUE_TEXT) return record3.goal;
-    current2 = record3.resumedFromRunId ?? null;
-  }
-  return null;
-}
 function continueInput(root, input) {
   const continuation = continuationOf(root, input.continueFrom, input.sessionDir);
   if (!continuation.resumable || !continuation.resume) throw new HarnessError("continuation_unavailable", `Run ${input.continueFrom} cannot be continued (${continuation.reason ?? "history_missing"}).`);
@@ -25280,6 +24995,7 @@ Attached saved file references:`);
       const own = [plan, resumed, profiles].filter((section2) => section2 !== null);
       const effectiveLaunch = {
         ...launch,
+        model: input.model ?? launch.model ?? null,
         ...sessionState ? { sessionState } : {},
         sections: own.length ? [...(launch.sections ?? []).filter((section2) => !own.some((entry2) => entry2.id === section2.id)), ...own] : launch.sections,
         tools: capabilities.tools,
@@ -25295,9 +25011,6 @@ Attached saved file references:`);
     const planResearchChild = input.plan === true && input.run.relation === "subagent";
     const sliceEnabled = slicePolicy.enabled && (harnessStateTools || planResearchChild);
     const sliceState = createSliceState(slicePolicy, sliceOf(root, runId));
-    const gateEnabled = harnessStateTools && !input.plan && !input.command && !input.automatic && !input.run.relation && !launchSwitchOff("XINGULAR_STOP_GATE");
-    const originalRequest = input.text.trim() === CONTINUE_TEXT ? requestOfChain(root, previousRun?.id ?? null) : null;
-    const stopGateState = gateEnabled ? createStopGateState(continuation?.todo) : null;
     let goalController = null;
     if (goalWanted && input.goal) {
       goalController = new GoalController({ onChange: (state) => updateRun(root, runId, (record3) => {
@@ -25416,15 +25129,7 @@ ${continuationPrompt(goalState)}` : null;
           ...sliceEnabled ? [{ name: WORK_SLICE_EXTENSION, factory: workSliceGuard({ policy: slicePolicy, state: sliceState, onRefuse: (event, reason) => {
             if (typeof event.toolCallId === "string") run2.emit("tool.refused", { toolCallId: event.toolCallId, name: event.toolName, code: "work_slice", reason: reason.slice(0, 2e3) });
           } }) }] : [],
-          // Last, so delivered subagent results and plan repair continue first and the gate sees them.
-          ...stopGateState ? [{ name: STOP_GATE_EXTENSION, factory: stopGate({
-            state: stopGateState,
-            initialTodo: continuation?.todo,
-            request: () => originalRequest,
-            sliceEnded: () => sliceEnabled && sliceState.endedBy !== null,
-            onEvent: (event) => run2.emit("extension.notice", { kind: "notify", level: "info", extension: STOP_GATE_EXTENSION, text: stopGateNotice(event) })
-          }) }] : [],
-          // After the todo gate: a goal continues a reply the gate let end (ADR-0072).
+          // A goal continues a reply the model ended (ADR-0072).
           ...goalController ? [{ name: GOAL_EXTENSION, factory: goalLoop({
             controller: goalController,
             check: launchSwitchOff("XINGULAR_COMPLETION_CHECK") ? null : sessionCheckModel,
@@ -25439,7 +25144,6 @@ ${continuationPrompt(goalState)}` : null;
         }),
         system,
         ...sliceEnabled ? { slice: { state: sliceState, maxToolCalls: slicePolicy.maxToolCalls } } : {},
-        ...stopGateState ? { stopGate: stopGateState } : {},
         ...goalController ? { goal: goalHandle } : {},
         // A command sends no request of its own, so the context update waits for the next turn.
         update: input.command ? null : update3,