@xingular/harness 1.4.0-unstable → 1.5.0-unstable

package/docs/architecture/02-sessions-and-runs.md

@@ -330,7 +330,7 @@ is approved but remains in progress; no completed cross-surface catalog is impli
   budget-ended reply is `interrupted` with terminal reason `slice_complete` (ADR-0053), unless it
   continues: a headless run as a new run (`continueSlice`), a terminal reply in place as its next
   slice (ADR-0070), both up to `maxSlices` and never after a fruitless or blocked slice. The budget
-  covers the whole reply: Pi emits `agent_start` for every continuation (a stop-gate nudge, delivered
+  covers the whole reply: Pi emits `agent_start` for every continuation (a slice continuation, delivered
   subagent results, a plan repair), so the guard starts a new slice only on a person's message.
   No call is refused for repeating: identical calls, a Bash check that keeps failing and repeated
   `edit`/`write` results on one path are allowed as often as the work needs, because a distinct read
@@ -342,20 +342,18 @@ is approved but remains in progress; no completed cross-surface catalog is impli
   check or recorded a finished item, and never after a checkpoint that is `blocked`. A run may turn
   the guard off with `workSlice.enabled: false`, and a launch may set `XINGULAR_WORK_SLICE=off` for
   every run in that process; with it off a reply has no boundary — no checkpoint, no continuation —
-  and ends only when the model stops or a person interrupts. A reply the model ends on its own is
-  subject to the todo gate (INV-RUN-15) and, in a goal, the goal loop (INV-RUN-16); a continuation carries the todo it left (`continuation.ts`).
-- **INV-RUN-15** A reply may not quietly end while its own todo list has open items (ADR-0069,
-  ADR-0072). In an attended top-level run (not plan, command, automatic, subagent or other related
-  runs) the **todo gate** acts at Pi's `agent_before_settle` boundary, unless the reply failed,
-  aborted or was ended by the slice guard: an item still `pending` or `in_progress` sends the reply
-  back with a displayed `xingular-stop-gate` message naming the open items and saying that the list
-  shows progress, not the limit of the work. No model is asked. A cap of three nudges per reply
-  applies, and no nudge follows one that produced no tool call other than `todo_write` or
-  `session_name`. Each nudge is an `extension.notice` from `stop-gate`. A reply settles `completed`
-  when no item is open; otherwise it is `interrupted` with terminal code `unfinished` and a
-  harness-written checkpoint, and a person continues it. **No model judges an ordinary reply**
-  (ADR-0072 removed ADR-0071's every-reply completion check); completion pressure there is the prompt
-  (`04-prompt.md`). `XINGULAR_STOP_GATE=off` at launch switches the gate off.
+  and ends only when the model stops or a person interrupts. A reply the model ends on its own
+  settles as it ends (INV-RUN-15); in a goal, the goal loop (INV-RUN-16) continues it. A
+  continuation carries the todo it left (`continuation.ts`).
+- **INV-RUN-15** A reply the model ends settles as it ends (ADR-0075): the harness never sends it
+  back and never overwrites its status from the todo list. The todo list is progress, not a gate.
+  Only three things settle a reply otherwise: a person's interrupt (`interrupted`), the work-slice
+  guard (INV-RUN-13), and a goal's stop (INV-RUN-16) — a goal that ends blocked settles
+  `needs_person`, and one that ends on a limit, a pause or a stall settles `unfinished`, each with a
+  harness-written checkpoint. **No model judges an ordinary reply** (ADR-0072 removed ADR-0071's
+  every-reply completion check); only a goal's completion claim is checked (INV-RUN-16). Carrying
+  the request to completion is the prompt's job (`04-prompt.md`). There is no stop gate, no nudge
+  and no `XINGULAR_STOP_GATE` switch.
 - **INV-RUN-16** A goal is the person's opt-in long run (ADR-0072). Only a person's own top-level run
   carries one (`sessions.run` `goal`, or `/goal` in the terminal); never a plan, command, unattended
   or child run. While its status is `active`, a reply that would end continues in place (the goal

package/docs/architecture/04-prompt.md

@@ -68,51 +68,55 @@ or permission. Structured sessions deliver it through `sessionLaunch`; the termi
 text with `requiredSkillsText` from Pi's loaded skills and appends it as a hidden request-time custom
 message. The section belongs to the request, so an identical one is delivered again.
 
-The fixed `harness-identity` section says `You are an AI agent running in <productName>.` and uses
-`env.productName` (default `Xingular Agent`). `Launch.standard: { cwd, project?: { name } | null }` requests shared role and working-folder
+The fixed `harness-identity` section says `You are an AI agent running in <productName>[, based on
+<model>]. You and the user share one workspace, and your job is to collaborate with them until their
+intended goal is completely handled.` It uses `env.productName` (default `Xingular Agent`) and
+`Launch.model` when the host knows the model. `Launch.standard: { cwd, project?: { name } | null }` requests shared role, personality and working-folder
 sections from `prompt/standard.ts`; the compiler supplies common connections, file and annotation
 guidance for the effective tools. Terminal preparation defaults to standard sections (explicit
 `standard: null` opts out); the host interactive path requests the same sections. Hosts may add
 attributed add-on and task context, not a duplicate standard role or connection policy (PROP-0040).
 
 Budgets (characters): variant sections 30,000 each (already capped at save, so never cut here);
-references 12,000; Wiki pointer 2,500; tools 8,000; reporting 18,000 (ADR-0073); the
-standard session's sections: role 1,400, autonomy 2,600, permission 1,800, steering 2,000, writing
-1,900 (ADR-0072); application sections their own `budget`.
+references 12,000; Wiki pointer 2,500; tools 8,000; reporting 12,000 (ADR-0076); the
+standard session's sections: role 1,400, autonomy 2,600, personality 1,200, permission 1,800,
+steering 2,000, writing 1,900 (ADR-0072); application sections their own `budget`.
 
 ## Reporting
 
 Every pack ends with the harness's `reporting` section ("Reporting your work",
 `REPORTING_GUIDANCE` in `prompt/reporting.ts`, imported by `prompt/compile.ts`). It is fixed text
-that shapes the final reply: lead with the outcome rather than the steps taken to reach it, and
-cover only what the person needs to act. The section defines content blocks, not a fixed heading
-list ([ADR-0008](../decisions/ADR-0008-flexible-reporting-guidance.md),
-[ADR-0073](../decisions/ADR-0073-large-reporting-prompt.md)): a change carries four required blocks
-— outcome, what changed, how to test, and what to do next — while a question stays one to three
-sentences and research carries only the blocks with content. How to test gives numbered steps with
-exact commands or URLs, the expected result, what the agent already ran, and what the person must
-run; what to do next names the person's action or says "Nothing needed". Optional blocks cover work
-beyond the request (with why), departures from a plan (what and why), work that needs a person's
-check (what is unverified, why, and the exact check), and open questions. Headings are the model's
-choice — "How to test", "Try it" and "Verify" name the same block — and a heading must name its
-content. The section ships five worked examples and an anti-pattern table, uses tables for files,
-checks and comparisons, and caps a change at about 20–60 lines. A person, application or mode format
-takes precedence. The section names no application, is never dynamic, and is never cut; its budget is
-18,000 characters (ADR-0073).
+that shapes the final reply. ADR-0076 adopts Codex's final-answer guidance (`gpt-6.1-sol`): the
+final answer is fully self-contained and focuses on the most important information, leads with the
+outcome, and explains what changed, why, how it was tested, and the material risks and limits, with
+the evidence needed to assess the conclusion and its practical limits. Routine verification is
+summarized instead of listed check by check; reasoning and evidence are ordered for assessment, not
+chronologically; and progress updates say what was learned, what remains uncertain and what the next
+step will resolve. Tables are used for mappings and comparisons. Headings are the model's: there is
+no required heading and no preferred set, and a shape-by-work table shows what different kinds of
+work need. Length follows complexity: a simple change is one or two sentences plus the validation, a
+larger one carries the reasoning, evidence and risks. Prose comes first; lists only when the
+information is genuinely parallel, sequential or easier to compare. The section ships two examples
+(a screen change and a blocked publish), the shape-by-work table and a four-line pre-send list; the
+exact command for a blocked login is in `autonomy`. A person, application or mode format takes
+precedence. The section names no application, is never dynamic, and is never cut; its budget is
+12,000 characters (ADR-0076), and the text it carries is about 3.7k characters, about 0.8k tokens
+measured with o200k.
 
 ## When a reply may end
 
 A reply ends when the request is done, when the work-slice guard ends it (INV-RUN-13), when a person
 interrupts, or when the work cannot continue without the person. An open todo item, a passing check,
-a partial result or a long task is not such a reason. An ordinary reply is held to this by two
-things (ADR-0069, ADR-0072): the words below, and the todo gate (INV-RUN-15), which sends back a
-reply that ends while its todo list has open items. **No model judges an ordinary reply**; a goal's
-completion claim is the one thing a model checks (INV-RUN-16). A reply that settles with work left is
-`interrupted` (`unfinished`, or `needs_person` for a blocked goal), never `completed`.
-
-The words decide what the model does before the gate has to act, and none of them may read as
-permission to stop with work left. A person's own session (`launch.standard`, `prompt/standard.ts`)
-reads five stable sections adapted from OpenAI Codex's gpt-6.1-sol instructions (Apache-2.0, see
+a partial result or a long task is not such a reason: the words below ask the model to carry the
+request to completion, and they are the only layer (ADR-0075). The harness does not send a reply
+back and does not mark it unfinished from the todo list; a reply the model ends settles `completed`.
+**No model judges an ordinary reply**; a goal's completion claim is the one thing a model checks
+(INV-RUN-16). A goal that ends blocked settles `needs_person`; a goal that ends on a limit, a pause
+or a stall settles `unfinished`.
+
+The words are what asks the model to carry on, and none of them may read as permission to stop with
+work left. A person's own session (`launch.standard`, `prompt/standard.ts`)
+reads six stable sections adapted from OpenAI Codex's gpt-6.1-sol instructions (Apache-2.0, see
 `NOTICE.md`), the same for every model so the terminal and a host read the same text (INV-PAR-1):
 
 - `role` — the assistant's job, and the extra work it does without asking (the obvious adjacent
@@ -126,6 +130,8 @@ reads five stable sections adapted from OpenAI Codex's gpt-6.1-sol instructions
   points to is the request; a question the request or files already answer is not a question for the
   person; the only reasons to stop, one of them a fix to a test or error that does not come from
   this session's work (and then say exactly what is needed).
+- `personality` — curious, thoughtful and candid; keeps its own judgment, disagrees when it has
+  reason and reconsiders when the evidence warrants it, without flattery or forced enthusiasm.
 - `permission` — authorisation persists; finish the authorised work first so that approval is the
   last step; no permission for reversible, read-only or already authorised work; a test or error
   that does not come from this session's work is reported, not fixed, unless the person asks (a
@@ -143,12 +149,12 @@ Other fixed text that shapes the end of a reply:
   it points to, is the scope; add steps as the work shows them; list a handoff's steps instead of one
   "remaining work" item; before ending, compare the request, not the list, with what is done and
   checked. An open step is work to do in this reply, not something to report.
-- `reporting` (`REPORTING_GUIDANCE`): opens with "Reporting is for work that is finished or genuinely
-  blocked". When work is not finished, the first line says so, gives the specific reason and names
-  the next step. The final reply is self-contained, says what could not be done or verified, never
-  closes with an "If you want..." offer, and stays near 60 lines. Its `## What would make this
-  complete` heading applies only when the work stopped short and says never to stop early to write
-  it.
+- `reporting` (`REPORTING_GUIDANCE`): the final answer is fully self-contained and focuses on the
+  most important information; it leads with the outcome and explains what changed, why, how it was
+  tested, and the risks and limits, with the evidence needed to assess the conclusion. Verification
+  is summarized, not listed check by check. Headings and length follow the content; a simple change
+  is one or two sentences plus the validation. A login the work needs is named with its exact
+  command.
 - `ask_user` (`tools/askUser.ts`): for a decision the request and files do not answer, never for
   permission to do work inside the request; no answer means continue with best judgment (Codex's
   Default-mode rule).

package/docs/architecture/07-tools-and-gate.md

@@ -152,8 +152,8 @@ beside the choices (INV-RC-3, INV-RC-4).
   ADR-0071) exists. The one exception is `update_goal` in a goal the person started: it is offered
   only while a goal exists, its `complete` is only a claim that the harness checks (INV-RUN-16), and
   its `paused` needs the person's word. The model cannot create, resume or limit a goal. When a
-  reply stops, the harness decides how it settled (INV-RUN-15) and writes the checkpoint from the
-  run's evidence.
+  reply stops, it settles as it ends unless a person interrupted it, the slice guard ended it, or a
+  goal stopped it (INV-RUN-15); a slice or goal stop writes the checkpoint from the run's evidence.
 - **INV-TOOL-10** Bash keeps one command budget on every surface: 120 seconds when the call says
   nothing, 300 seconds as the ceiling without a `reason`, 900 seconds as the maximum, and a timeout
   returns the partial output with a narrowing instruction instead of blocking the reply.

package/docs/architecture/10-server-protocol.md

@@ -79,11 +79,12 @@ harness → host   { v: 1, id, call, params }          host → harness   { v: 1
 - The run-event stream adds `checkpoint` (the bounded handoff) and `heartbeat` (steps, elapsed time,
   last tool, compactions, slice, call budget). Hosts must accept both; an unknown event type is still
   relayed in order (INV-RUN-3).
-- `terminalCode` gains `needs_person` and `unfinished` (ADR-0069, ADR-0072): a reply that settled with
-  work left — `needs_person` when the run's goal ended `blocked`, `unfinished` when todo items stayed
-  open or a goal was paused, stalled or limited. Both are `interrupted`, carry a `checkpoint`, and
-  are not auto-continued; a host should offer the person Continue, as it does for `slice_complete`.
-  Stop-gate nudges arrive as `extension.notice` events with `extension: 'stop-gate'`.
+- `terminalCode` gains `needs_person` and `unfinished` (ADR-0072, ADR-0075): a goal that settled with
+  work left — `needs_person` when it ended `blocked`, `unfinished` when it was paused, stalled or
+  limited. Both are `interrupted`, carry a `checkpoint`, and are not auto-continued; a host should
+  offer the person Continue, as it does for `slice_complete`. An ordinary reply with open todo items
+  settles `completed`. Extension notices arrive as `extension.notice` events (for example
+  `work-slice` and `goal`).
 - `sessions.run` accepts `goal { objective, rounds?, hours? }` (ADR-0072, INV-RUN-16) for a person's
   own top-level run; it is refused with `invalid_request` for a plan, command, unattended or child
   run, or an empty or over-long (4,000 character) objective. The objective is the request, and the

package/docs/architecture/11-terminal.md

@@ -378,11 +378,11 @@ Terminal tool-gate and work-slice refusals are relayed as `tool.refused` events
 
 Terminal replies carry the same work-slice guard as structured runs: 320 tool calls or 60 minutes,
 with no new-token limit by default (PROP-0044), then a refusal that asks the model to stop and report
-where it is. Terminal replies also carry the todo gate (INV-RUN-15, ADR-0069, ADR-0072): the
-extension sends a reply that ends with open todo items back, up to three nudges, each `notice`
-telemetry recorded as `extension.notice`, and at settle sends a harness-written `checkpoint` and the
-`needs_person` or `unfinished` code, which the controller records on the active run, so an App
-reading the same session sees the handoff. No model judges an ordinary reply. Plan replies are not gated. A reply that
+where it is. An ordinary terminal reply settles as it ends (INV-RUN-15, ADR-0075): the terminal
+never sends it back and never marks it unfinished from the todo list. A `/goal` is the only layer
+that continues a reply; a goal that stops blocked, paused or at a limit sends a harness-written
+`checkpoint` and the `needs_person` or `unfinished` code, which the controller records on the active
+run, so an App reading the same session sees the handoff. No model judges an ordinary reply. A reply that
 reaches its budget after doing work continues in place as its next slice (ADR-0070): a
 `xingular-slice-continue` message in the same run, a checkpoint and a notice per boundary, up to
 `maxSlices` (8). A fruitless, blocked, failed, aborted or plan slice, or one whose todo items are all
@@ -406,8 +406,8 @@ resume)`, `Goal unmet (...)` or `Goal achieved (...)`.
 
 The goal lives in the Pi session as a `xingular-goal-state` entry, so a reopened conversation shows
 it, as `paused`: nothing resumes by itself. The model gets `get_goal` and `update_goal` only while a
-goal exists (INV-TOOL-9). The goal loop is a second extension after the todo gate and before slice
-continuation; a goal's slices continue even when every todo item is done. `/goal` is a `session`
+goal exists (INV-TOOL-9). The goal loop runs before slice continuation; a goal's slices continue even
+when every todo item is done. `/goal` is a `session`
 command that uses `sessions.run` with `goal` (page 10); in plan mode the loop stays silent.
 
 ## Liveness and a reply that stops working (INV-RUN-14, ADR-0054)

package/docs/decisions/ADR-0008-flexible-reporting-guidance.md

@@ -5,11 +5,11 @@ status: accepted
 created: 2026-10-21
 updated: 2026-10-21
 supersedes: ADR-0007
-amended_by: ADR-0073
+amended_by: ADR-0073, ADR-0074
 ---
 # ADR-0008 — Flexible reporting guidance with optional human inspection
 
-> **Amended by [ADR-0073](ADR-0073-large-reporting-prompt.md):** flexible headings stand; the `reporting` section now names required content blocks and ships worked examples, and the later fixed headings (ADR-0068) are gone.
+> **Amended by [ADR-0073](ADR-0073-large-reporting-prompt.md):** flexible headings stand; the `reporting` section now names required content blocks and ships worked examples, and the later fixed headings (ADR-0068) are gone. **Amended again by [ADR-0074](ADR-0074-report-content-not-report-blocks.md):** the required blocks are gone too, and human inspection is once more the only optional by-hand block.
 
 ## Context and decision
 

package/docs/decisions/ADR-0069-stop-gate-and-finish.md

@@ -1,9 +1,10 @@
 ---
 id: ADR-0069
 title: A stop gate and a finish tool; the model's checkpoint tool is removed
-status: accepted
+status: superseded
 created: 2026-10-31
-updated: 2026-10-31
+updated: 2026-11-01
+superseded_by: ADR-0075
 supersedes: partial — PROP-0041 (the model-written checkpoint), ADR-0068 (when the completion heading applies), ADR-0063 (scope of the unfinished-work guidance)
 related:
   - STUDY-0004
@@ -11,6 +12,11 @@ related:
 ---
 # ADR-0069 — A stop gate and a finish tool; the model's checkpoint tool is removed
 
+> **Superseded by [ADR-0075](ADR-0075-no-todo-gate.md):** the stop gate and the `unfinished` status
+> that open todo items produced are removed. A reply the model ends settles `completed`; the goal
+> loop and the work-slice guard keep their statuses. The `finish` tool was already removed by
+> ADR-0071.
+
 > **Amended by [ADR-0071](ADR-0071-completion-check.md):** `finish` is removed; a completion check (the run's own model, fresh context) now decides `continue` / `needs_person` / `done` when a reply that did work ends with its list closed.
 
 ## Context

package/docs/decisions/ADR-0070-terminal-slice-continuation.md

@@ -11,6 +11,9 @@ related:
 ---
 # ADR-0070 — A terminal reply continues across work slices in place
 
+> **Amended by [ADR-0075](ADR-0075-no-todo-gate.md):** the stop gate is removed; the slice guard
+> still resumes a reply at its slice boundary.
+
 ## Context
 
 A headless run that stops at its work-slice budget already continues on its own (`continueSlice`,
@@ -43,4 +46,4 @@ next slice continues from it", which was false in the terminal.
 - A long terminal task runs up to eight slices without a person, and Esc still stops it at once.
 - A continued terminal reply is one run record with several checkpoints, where a headless one is a
   chain of runs; `sliceOf` keeps counting the headless chain.
-- The stop gate stays silent at a slice boundary and resumes in the next slice.
+- A reply at its slice boundary continues in the next slice; there is no todo gate (ADR-0075).

package/docs/decisions/ADR-0072-codex-prompts-and-goal.md

@@ -13,6 +13,9 @@ related:
 ---
 # ADR-0072 — Codex's prompts and `/goal`; the completion check moves behind `/goal`
 
+> **Amended by [ADR-0075](ADR-0075-no-todo-gate.md):** the todo gate is removed, so ordinary replies
+> rely on the prompt alone. The goal loop and its completion claim check stay.
+
 ## Context
 
 ADR-0071 asked a model to judge, at the end of **every** reply that did work, whether the request was

package/docs/decisions/ADR-0073-large-reporting-prompt.md

@@ -1,9 +1,10 @@
 ---
 id: ADR-0073
 title: A large, content-block reporting prompt
-status: accepted
+status: superseded
 created: 2026-11-01
 updated: 2026-11-01
+superseded_by: ADR-0074
 supersedes: partial — ADR-0068 (its required headings and fixed-label rule)
 amends: ADR-0008 (flexible headings stand; required content blocks are added)
 related:
@@ -14,6 +15,10 @@ related:
 ---
 # ADR-0073 — A large, content-block reporting prompt
 
+> **Superseded by [ADR-0074](ADR-0074-report-content-not-report-blocks.md):** the four required
+> blocks, the "Nothing needed" ending, the five examples and the 18,000-character budget are
+> replaced by content questions, an evidence line, an optional by-hand block and free headings.
+
 ## Context
 
 The person reading final replies asked for three things the 3,400-character `reporting` section did

package/docs/decisions/ADR-0074-report-content-not-report-blocks.md

@@ -0,0 +1,90 @@
+---
+id: ADR-0074
+title: Report content, not report blocks
+status: superseded
+created: 2026-11-01
+updated: 2026-11-01
+superseded_by: ADR-0076
+supersedes: ADR-0073 (its four required blocks, five examples and 18,000-character budget)
+amends: ADR-0008 (human inspection is the only by-hand block)
+related:
+  - ADR-0008
+  - ADR-0073
+  - STUDY-0006
+---
+# ADR-0074 — Report content, not report blocks
+
+> **Superseded by [ADR-0076](ADR-0076-codex-final-answer-verbatim.md):** the four content
+> questions, the human-check and next-step blocks, the evidence table, the anti-pattern table and
+> the three examples are replaced by Codex's final-answer and technical-communication text.
+
+> **Supersedes [ADR-0073](ADR-0073-large-reporting-prompt.md):** the four required blocks, the
+> "Nothing needed" ending and the 18,000-character budget are replaced.
+
+## Context
+
+ADR-0073 made a change carry four required blocks — outcome, what changed, how to test, what to do
+next — and put both the agent's own runs and the person's steps inside "how to test". In real
+replies the two merged: a section headed for the person's testing listed `npm run typecheck —
+passed` and `npm test — 212 test files passed`, checks the person was never going to repeat. The
+same guidance required "or say 'Nothing needed'", and replies ended with "Nothing needed next"
+even when the work was complete and visible.
+
+Headings also collapsed. The four block names and their synonyms ("How to test", "Test it", "Try
+it", "Verify") gave the model one vocabulary, so unrelated work — a document, a diagnosis, a
+publish — arrived under "What changed / How to check / Next step".
+
+The person asked for three things: a by-hand section for checks only a person can make (a screen,
+a sign-in, a diff or PR, a publish), no filler ending, and headings that follow the content. The
+earlier design already had the principle: ADR-0008 made **Need human inspection** optional and said
+not to use it "for checks already performed or generic risks". ADR-0073 folded that block into the
+required set and lost the distinction.
+
+## Decision
+
+Replace `REPORTING_GUIDANCE` in [`src/prompt/reporting.ts`](../../src/prompt/reporting.ts) with a
+~8.9k-character text (about 2.1k o200k tokens) that defines content questions rather than blocks:
+
+- The reply answers what happened, what changed or was decided, what only a person can check, and
+  what they do next — in any words and any order. Most replies answer two or three.
+- The checks the agent ran are evidence: one line each, command and result. They are never steps
+  for the person, and never appear in a section headed for the person's testing.
+- A by-hand check is optional and covers only what the agent could not do: open a screen, sign in,
+  read a document for tone, review or merge a diff, publish, deploy, use a device. It gives the
+  shortest sequence, what to look at, and the result that means it works. When nothing needs a
+  person, the block is absent — no "no manual check" line.
+- A finished reply with nothing left ends on its last real point. "Nothing needed", "Nothing needed
+  next" and "No action required" are banned.
+- There is no required heading and no preferred set; the section gives cross-domain examples and a
+  shape-by-work table, not a vocabulary, and says not to repeat one heading set.
+- Three worked examples: a screen change, a backend change, a publish. The old examples' "Nothing
+  needed next" endings are gone.
+
+`REPORTING_BUDGET` falls from 18,000 to 12,000 characters. The section stays last in the stable
+prefix and is never cut.
+
+## Consequences
+
+- The stable prefix shrinks by about 6.9k characters (15,809 → 8,921) and about 1.6k o200k tokens
+  (3,736 → 2,108). Existing sessions miss the provider cache once after the upgrade; the price of a
+  request is measured only with real application requests under INV-PRM-8.
+- [`src/prompt/compile.test.ts`](../../src/prompt/compile.test.ts) checks the content questions, the
+  evidence rule, the by-hand rule, the ending ban, the heading freedom, three examples, the size
+  range and the 12,000 budget.
+- No data, storage or server-protocol change; the App needs a rebuilt harness only.
+- Risk: without four required blocks, a reply could go thin. The four content questions and the
+  "before you send" list are the guard; whether replies keep the shape is checked on real work, not
+  by a test.
+
+## Alternatives
+
+- **Keep the four blocks and only ban "Nothing needed".** Rejected: the merge of the agent's runs
+  with the person's checks is the defect, and it comes from the block's own text.
+- **Give the agent a separate "what I ran" block.** Rejected: one line of evidence is enough, and a
+  block invites the ceremony the person objected to.
+- **Ban headings entirely.** Rejected: short replies drift into prose, and a report still needs
+  names for its parts.
+- **Keep ~15.8k characters and rewrite the rules in place.** Rejected: the person chose a leaner
+  text, and the five examples restated rules already in prose.
+- **Require the by-hand block on every change.** Rejected: most backend work has nothing a person
+  can check, and an always-present block produces filler.

package/docs/decisions/ADR-0075-no-todo-gate.md

@@ -0,0 +1,84 @@
+---
+id: ADR-0075
+title: No todo gate; a reply ends when the model ends it
+status: accepted
+created: 2026-11-01
+updated: 2026-11-01
+supersedes: ADR-0069 (its stop gate), ADR-0072 (its "the todo gate stays")
+related:
+  - ADR-0069
+  - ADR-0072
+  - STUDY-0004
+---
+# ADR-0075 — No todo gate; a reply ends when the model ends it
+
+> **Supersedes the todo gate of [ADR-0069](ADR-0069-stop-gate-and-finish.md)** and the line in
+> [ADR-0072](ADR-0072-codex-prompts-and-goal.md) that kept it. The goal loop and its claim check
+> stay.
+
+## Context
+
+ADR-0069 added the stop gate: in an attended top-level reply, an item still `pending` or
+`in_progress` at Pi's `agent_before_settle` boundary sent the reply back with a displayed
+`xingular-stop-gate` message, up to three nudges, and then settled the run
+`interrupted{unfinished}` with a harness-written checkpoint.
+
+In use the messages read as noise. "Harness stop gate (1/3): your reply ended with 2 open todo
+items…" appears in the transcript of a person's own session, and a stale item the model forgot to
+close marks the run unfinished even when the work is done. The person asked for the nudges and the
+unfinished status to go, and for the prompt to relax instead.
+
+The peer check on 2026-11-01 does not make this an obvious outlier either way:
+
+| Harness | Todo nudge at the end of a turn | Evidence |
+|---|---|---|
+| omp | **Yes.** `TodoTracker.checkCompletion()` appends "You stopped with N incomplete todo item(s)… Please continue" as a developer message and schedules a continuation, up to `todo.remindersMax` (default 3); it skips a reply awaiting the person and also nudges mid-run after 12 mutating tools | `external/omp/packages/coding-agent/src/session/todo-tracker.ts:221`, `src/tools/settings.ts:360-380` |
+| Claude Code | No bounce. A gentle reminder to use TodoWrite ("This is just a gentle reminder - ignore if not applicable"); a `Stop` hook is user configuration | Extracted prompt `system-reminder-todowrite-reminder.md`, `ccVersion` 2.1.139 |
+| Codex | No bounce. `update_plan` is opt-in since 0.152 and enforces nothing at the end of a turn | STUDY-0004; 0.152 release notes |
+| Kimi CLI | No bounce. A todo tool and instructions only | `external/kimi-cli/src/kimi_cli/tools/todo/set_todo_list.md` |
+| OpenHands, SWE-agent, smolagents | No todo gate | No todo tool or no end-of-turn enforcement |
+
+So this harness had copied a real design, but it is the minority design among the studied peers,
+and its messages are the thing the person objected to.
+
+## Decision
+
+Remove the gate:
+
+- Delete the nudge extension, its state, `nudgeText`, `stopGateNotice`, `MAX_STOP_GATE_NUDGES`, and
+  the `XINGULAR_STOP_GATE` switch.
+- A reply the model ends settles `completed`. The harness does not send it back and does not
+  overwrite its status from the todo list.
+- A person's interrupt, the work-slice guard (INV-RUN-13) and a goal's stop (INV-RUN-16) keep their
+  statuses and checkpoints. A blocked goal settles `needs_person`; a goal on a limit, a pause or a
+  stall settles `unfinished`.
+- The goal/checkpoint helpers move to `sessions/goalStop.ts`; the goal check's model helper moves to
+  `completionCheck.ts`.
+- The prompt keeps the work-slice sentence as `WORK_SLICE_GUIDANCE`, and `TODO_GUIDANCE` is relaxed:
+  the list is a progress aid, the request is the scope, and a step left open is explained in the
+  reply. No text says a reply is sent back.
+- A login that blocks the work is answered with the exact command the person must run (see
+  `04-prompt.md` § Reporting).
+
+## Consequences
+
+- An early stop is no longer caught by the harness. The prompt is the only layer that asks the model
+  to finish the request, and a person reading the reply has to notice a stop with work left.
+- The App no longer shows an interrupted-run notice for open todo items; it still does for a slice,
+  a goal and a person's interrupt.
+- The stable prefix loses the old `STOP_GATE_GUIDANCE` sentence and gains the credential rule in the
+  reporting section; existing sessions miss the provider cache once after the upgrade.
+- `XINGULAR_STOP_GATE` is retired and ignored if set. No data or protocol change; run records
+  written before this change keep their statuses.
+
+## Alternatives
+
+- **Keep the gate and only make it opt-in, off by default.** Rejected: the machinery and its
+  messages would still exist for the default path people read, and the harness would carry a
+  capability nobody turns on.
+- **Keep one reminder.** Rejected: the person asked for the nudges to go, and one reminder still
+  writes a harness message into their reply.
+- **Remove the message but keep the `unfinished` status.** Rejected: the status comes from a list the
+  model may not maintain, so a stale item would mark finished work unfinished with no way to fix it.
+- **Keep the gate.** Rejected: it is the thing the person objected to, and the majority of the
+  studied peers leave the end of a turn to the prompt.

package/docs/decisions/ADR-0076-codex-final-answer-verbatim.md

@@ -0,0 +1,93 @@
+---
+id: ADR-0076
+title: Codex's final-answer guidance, adopted verbatim
+status: accepted
+created: 2026-11-01
+updated: 2026-11-01
+supersedes: ADR-0074 (its four content questions, human-check block, next-step block and examples)
+related:
+  - ADR-0074
+  - ADR-0075
+  - STUDY-0006
+---
+# ADR-0076 — Codex's final-answer guidance, adopted verbatim
+
+> **Supersedes [ADR-0074](ADR-0074-report-content-not-report-blocks.md):** the four content
+> questions, the human-check block, the next-step block, the evidence table, the anti-pattern table
+> and the three examples are replaced by Codex's final-answer and technical-communication text.
+
+## Context
+
+ADR-0074 replaced four required blocks with four content questions, a one-line evidence rule, an
+optional human-check block, a next-step rule and three examples. It removed the filler ending and
+brought the section to 9,235 characters (2,188 o200k tokens).
+
+A rule-by-rule comparison with Codex's `gpt-6.1-sol` prompt found that most of the autonomy and
+permission text was already Codex's, word for word, while the report section carried the strictness:
+18 prohibition phrases, 19 obligation words, a pre-send checklist and an anti-pattern table, against
+Codex's 454-token `## Final answer` block, which mostly describes qualities and rendering.
+
+The person chose Codex's wording for the report: self-contained final, technical communication,
+evidence and limits, table guidance and length by complexity. They also added the model name to the
+identity, adopted Codex's personality paragraph and unclear-scope sentence (with `ask_user`), and
+adopted Codex's tool hygiene, test restraint and skill rules.
+
+## Decision
+
+- **Identity.** `harness-identity` carries the product name, `Launch.model` when the host knows it,
+  and Codex's goal sentence: "You and the user share one workspace, and your job is to collaborate
+  with them until their intended goal is completely handled." The model name is a stable-prefix
+  line; a `/model` switch after the pack is compiled leaves it naming the model the session started
+  with.
+- **Personality.** A new standard section (`prompt/standard.ts`, order 22) carries Codex's
+  personality paragraph, with "As Codex" changed to "As an AI agent" so the harness names no other
+  product.
+- **Unclear scope.** Codex's sentence replaces the harness wording: "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." A following sentence names `ask_user`
+  for the question.
+- **Reporting.** `REPORTING_GUIDANCE` becomes Codex's final-answer block and technical-communication
+  paragraphs: self-contained, most important information, outcome first, what changed and why, how
+  it was tested, material risks and limits, the evidence needed and its limits, verification
+  summarized rather than listed, progress updates as learned/uncertain/next. Tables for mappings and
+  comparisons. Headings stay free. A shape-by-work table says what different work needs. Length
+  scales with complexity. Prose first, lists when the information is parallel or sequential. Two
+  examples (a screen change, a blocked publish) and a four-line pre-send list replace the old
+  blocks, the anti-pattern table and the three examples.
+- **Removed from reporting.** The four content questions, "Your checks are evidence", "What only a
+  person can check", "What the person does next", "What to leave out", "Tone", "Claims carry
+  evidence" and the anti-pattern table. The exact command for a blocked login remains in
+  `autonomy` and in the blocked-publish example.
+- **Tools.** Codex's work rules join the Native guidance: `rg` first, no decorative command
+  separators, shell text treated as code, no reused `$HOME`, no long blocking sleeps, no tests for
+  reversible changes or tests that mirror the implementation, and broadening tests only when
+  justified. Codex's skill rules (SKILL.md, user precedence, announce the first use, `$name`,
+  missing skill) and its plugin principle join the Wiki guidance.
+- `REPORTING_BUDGET` stays 12,000; the text is 3,697 characters (about 800 o200k tokens) and is
+  never cut.
+
+## Consequences
+
+- The stable prefix shrinks by about 5.5k characters and 1.3k tokens. Existing sessions miss the
+  provider cache once after the upgrade.
+- The report no longer has a by-hand check block or a next-step block. A person reading a reply gets
+  the outcome, the change, the evidence and the risks, and must notice when the reply leaves
+  something undone; ADR-0075's removal of the todo gate already accepted that.
+- The personality section adds a sixth standard section; the terminal and every host read the same
+  text (INV-PAR-1).
+- `Launch.model` is a new optional launch field; hosts that do not know the model get the identity
+  without "based on".
+- No data, storage or server-protocol change.
+
+## Alternatives
+
+- **Keep ADR-0074 and only trim the anti-patterns.** Rejected: the comparison showed the strictness
+  was in the block structure itself, and the person chose Codex's wording.
+- **Copy Codex's whole prompt.** Rejected: its channels, `update_plan`, `functions.exec`, apps and
+  plugin mechanics do not exist in this harness; only the report, personality, permission and work
+  rules apply.
+- **Keep the human-check and next-step blocks alongside Codex's text.** Rejected: they were the two
+  blocks the person asked to remove, and Codex's technical communication covers what remains.
+- **Make the model name dynamic.** Deferred: a `/model` switch would need the identity in a dynamic
+  section or a recompile, and both change the cache contract; the stable line is the simpler
+  starting point.

package/docs/releases/1.4.0-unstable.md

@@ -14,5 +14,12 @@ Unstable preview of the current Harness work. Install with `npm install @xingula
 - **Terminal and session fixes.** Terminal behavior now accounts for the goal lifecycle, retains the
   right completion behavior, and includes related prompt, status and lifecycle updates.
 
-Test suites were not run for this candidate, at the request to bypass tests. The release workflow
-still requires CI and exact-tarball smoke checks before publication.
+Test suites were not run for this candidate, at the request to bypass tests.
+
+Published from commit `5f4c907` with a manual `npm publish --access public --tag unstable`, after the
+reviewed candidate was built from the same commit (SHA-256
+`2b1c12ddcd4c63a57714ab3538ff5198dec88d408230a0ef42bb8ece22cffe00`). The published tarball has that
+relation recorded by its npm integrity, `sha512-zlPE8HB3X0iR7AqELgYMVJzWjZMlEFdOKCjBJHyxQreWaDwyGnZ5M83rcA4Op/+CgGpl8BuYwFOcjcXa6Fayeg==`.
+Because the suites and the exact-tarball smoke checks did not run, and the workflow's OIDC publish path
+was not used, this version carries no provenance attestation and `scripts/release-verify.mjs` cannot
+verify it. The release workflow's gates are unchanged for the next release.