Two controls that did nothing, and instructions worth reading

**Switching mode mid-reply did nothing.** The mode was snapshotted when the
reply began, so changing to Auto during a long agent reply went on asking about
every call until the next turn. The same snapshot held the chat's allow list,
which means "Always allow this" was accepted, written to the row, and then
ignored for the rest of the reply that had just asked about it -- the same bug,
in the quieter place nobody reported.

`agent/session.py:refresh` re-reads exactly those two, between rounds and never
within one. A round's calls are authorised together, so a switch must not
retroactively approve what is already queued -- which is the property the
reply-long snapshot was protecting by accident, and the reason this is not
simply moved into `_authorise`. It mutates in place, because `as_approved`
copies field references and a replacement would leave the round's approved copy
pointing at the old context.

**The composer's highlighting stayed behind after sending.** htmx fires
afterSwap and afterSettle *before* afterRequest, and the composer empties itself
from `hx-on::after-request` -- so every repaint ran while the box still held the
message. It repaints on afterRequest and on `reset` as well now, deferred a
frame: a form's reset event fires before its fields are actually cleared, so
reading the value in the same turn paints the text that is about to vanish.
Driven under a DOM stub reproducing htmx's real ordering, and confirmed to fail
without the fix.

**plan_update, audited.** It never said to mark a task `doing`, so the plan only
ever showed work already finished, which is the opposite of "what somebody reads
to see where you are". It never said several changes fit in one call, so a model
spends a round per task. And `done` now means checked rather than written.

**New: core.engineering**, an agent-chat fragment about conduct rather than
about any language -- run what you write, find the project's own build and test
commands rather than guessing, read before editing, change one thing at a time,
read the error instead of guessing at a fix, do not broaden an except to make
output clean, and say what you did not check. Every line is about the gap
between having written something and knowing it works, which is the gap a model
closes by asserting.

That pushed the shipped harness to within 1,300 characters of its ceiling, where
crossing it silently severs the project's own AGENTS.md. The ceiling is 20,000
and the test pins a margin as well as a fit -- the headroom is also where an
administrator's own wording goes, and an override is usually longer than the
default it replaces.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Jaroslav Beneš
2026-08-04 12:36:50 +02:00
parent 35b85a9cda
commit 5984d90fb0
8 changed files with 243 additions and 15 deletions
+46 -7
View File
@@ -685,6 +685,42 @@ BUILTIN: tuple[Fragment, ...] = (
"not stop halfway to report progress and wait to be told to continue."
),
),
Fragment(
key="core.engineering",
label="Working on code",
group=GROUP_CORE,
order=112,
families=("agent",),
hint="An agent chat only, where there is a machine to check things on. "
"Every line here is about the gap between having written something and "
"knowing it works, which is the one a model closes by asserting rather "
"than by testing: the failure is not bad code, it is confident code "
"nobody ran. Deliberately about *conduct* rather than about any "
"language — style belongs to the project, and its own AGENTS.md is "
"where a project says so.",
default=(
"- Working on code, on this machine:\n"
" - Run what you write. A script you have not run is a draft, and "
"“this should work” is not a result. If you cannot run it, say that "
"plainly rather than implying you did.\n"
" - Find out how the project is built, tested and linted before "
"guessing — a README, a Makefile, a pyproject or package.json — and use "
"what is there rather than a command you would have chosen.\n"
" - Read a file before changing it, and match what is around you: the "
"naming, the error handling, the way the existing code is laid out. Code "
"that reads as though it came from somewhere else is a cost even when it "
"works.\n"
" - Change one thing, check it, then change the next. A dozen edits "
"checked at the end leave you without the one that broke it.\n"
" - Read what a failure actually says. Guessing at a fix and running it "
"again is slower than reading the error once, and it hides the cause.\n"
" - Do not silence a problem to make output clean: a broadened except, a "
"removed assertion or a skipped test buys a green run and keeps the bug.\n"
" - Say what you did and what you checked, including what you could not "
"check. If something is still broken, say so — being told a job is "
"finished when it is not is worse than being told it is hard."
),
),
Fragment(
key="core.objective",
label="Working to an objective",
@@ -1115,13 +1151,16 @@ BUILTIN: tuple[Fragment, ...] = (
"the point of it is being able to see where things are while they are "
"still moving.",
default=(
"- There is a plan for this work, set out below. Keep it current: call "
"plan_update when a task or a phase finishes, when something you find "
"changes what needs doing, and when a task turns out to be unnecessary. "
"Do it as you go rather than at the end — the plan is what somebody reads "
"to see where you are. If what you find makes the plan wrong rather than "
"merely incomplete, say so and ask with ask_user rather than quietly "
"planning something else."
"- There is a plan for this work, set out below. Keep it current with "
"plan_update as you go rather than at the end: mark a task “doing” when "
"you start it and “done” once you have checked it works, drop one that "
"turns out to be unnecessary, and add work the plan did not anticipate "
"when you find it. Several changes go in one call. The plan is what "
"somebody reads to see where you are, so a plan updated only at the end "
"is a report rather than a plan. Updating it is bookkeeping, not a "
"milestone — carry straight on with the work afterwards. If what you find "
"makes the plan wrong rather than merely incomplete, say so and ask with "
"ask_user rather than quietly planning something else."
),
),
Fragment(