session, prompt, tui3: answers stand against the completion check (round 2 of #1065) #1070

Round 2 of #1065. Round 1 (#1067) was the initial cleanup: the completion check sees the whole answer, [no change] ends a wrong carry-on without replacing the answer, and system.md gained the answer / answer-or-change / when-corrected / messages-from-codeaf sections. This issue collects what round 1 found but deliberately left out of scope. The owner picks the approach per item.

A. The completion check judges a turn against the wrong evidence

Problem. The reader's request is the current turn's ask (turnAsk, reset per turn in forgetOwedLocked), but its evidence is the whole conversation. readRemains builds the page from a.snapshot() (internal/session/checkpoint.go), so the ledger, the "written or changed" list and the results include earlier turns. A write made and reverted several turns ago, or a decision recorded earlier, shows up as work "this ask" left unfinished. The check then raises a note about something the person is not currently asking for. An aside in the person's message, such as naming a model they like, is read as an instruction to change code.

Options.

1. Scope the digest to the current turn: messages from the turn's opening user message onward, plus results that landed in the turn.
2. Keep prior context but label it: an "earlier in this conversation" section the reader is told is background, never evidence of an unfinished ask.
3. Also tighten checkpointRemainsAsk: judge only what the latest request asks for, and treat remarks and preferences as context, not instructions.

Recommended: 1 plus the wording in 3.

B. [no change] after checking the note does not count

Problem. [no change] is honoured only as the very next reply to the check's note (answeredNoteUnchanged). A model that first verifies the note with a read-only tool call (e.g. a git diff), then correctly replies [no change], is not honoured. The turn is read again, costing another reading and possibly another carry-on up to the cap. The reply is still hidden and the prior answer still stands, so the harm is cost and churn, not a lost answer.

Options.

1. Honour the token when every call between the note and the token was read-only (no write/edit/bash that changes the tree, no task started).
2. Keep the strict rule, but tell the model in the carry-on lead to reply [no change] directly, and verify only if it intends to change something.
3. Honour it always, and rely on the reader's next pass only when the tree changed since the note.

C. A model that argues instead of replying [no change] still buries the answer

Problem. If the model ignores the lead and writes a prose rebuttal, the rebuttal is the turn's last message. The fold keeps it as the answer and the real deliverable goes under worked. Round 1 fixed the harness side only for models that follow the protocol.

Options.

1. After a carry-on, keep the pre-note answer as the standing answer unless the continuation changed files, started work, or produced a reply at least as complete (e.g. not shorter than a threshold relative to the prior answer).
2. Detect a rebuttal shape (the reply addresses the note or check rather than the person) and treat it as [no change].
3. Draw both: the prior answer stands, and the continuation's reply is a collapsed "check note answered" row under it.

Recommended: 1, with 3 as the display.

D. A folded answer is labelled as a work step

Problem. Inside the worked fold, a step is a paragraph plus the calls that follow it. When an answer is followed by calls made in response to a carry-on, the answer is drawn as a step row titled with its own first line and carrying those calls ("… · 1 call"). It reads as narration, not as the answer the person was given.

Options.

1. A settled answer paragraph is never a step title. Draw it as its own "answer" row in the fold, and give following calls their own step.
2. Split steps at a carry-on boundary, so the continuation's calls start a new step.

E. Deferred from the round 1 PR

• A correctly placed [no change] can still reject a real gap. Should a second reading confirm the token?
• Display filter. The display hides a lone [no change] without context, while the harness honours it only in context. It flashes while streaming; --once prints raw deltas; feed.growSettledAnswer is unguarded.
• Process vs outcome. The reader sometimes raises process complaints ("reads were not one per step") unrelated to the deliverable. Should checkpointRemainsAsk judge only the outcome?
• system.md contradictions. DELIVERABLES ARE FILES, born on disk vs answering in the reply. ## Work or words (hand-off sizing) vs the new # Answer or change.
• Prompt length and emphasis. Round 1 raised the prefix waivers by 2,035 bytes on both profiles. Rewrite the ALL-CAPS emphasis across system.md in plain, reasoned rules, cut duplicated laws to pay the waivers back, and check the lean profile keeps what small models need.
• Other prompts. Apply the same answer rules to the worker, quick, divide and revise prompts where they draw a person-facing reply.

Acceptance

• Each item above has a ruling (option picked or explicitly declined) recorded here.
• A–D each land with a test that fails on today's dev.
• A live check on deepseek/deepseek-v4.1-flash in the real TUI, with the check running: a multi-turn conversation where an earlier turn edited and reverted a file. A later question-only turn is not carried on about that edit, and its answer is the visible final message.

Drafted with CodeAF · reviewed and owned by the author