github feder-cr/AIHawk v0.59.0
0.59.0

latest releases: v0.63.0, v0.62.0, v0.61.0...
2 hours ago

Two defects a person hits while the agent is working, both found by driving
the running page with a browser and measuring it rather than by reading it.

JUMP TO LATEST LOST THE RACE. It asked for a smooth scroll, which computes a
destination and animates to it over a few hundred milliseconds, and every row
arriving during the animation pushes the anchor further down. Measured with the
agent working: one press moved the view 2,700px and still left 303px to go, the
anchor 282px below the fold, the button still on screen - and the content had
grown 283px while the animation ran, which is almost exactly the shortfall.
Press again and it is one step behind again, forever. The same press with the
run finished landed 20px from the bottom and the button went away.

An animation cannot arrive at a target that moves. It lands at once now, and
from there the stylesheet keeps the view at the bottom by itself - #anchor is
the one thing in the log with overflow-anchor:auto - so the button stops being
a jump and becomes a follow. There is no motion left to reduce, which is why
the reduced-motion reading that used to be there is gone rather than kept.

AND IT CARRIES THE COUNT, because while a reader is scrolled up nothing on
screen says the agent is alive: the clock on the running step, the Thinking
row, the time climbing, all of them are drawn at the BOTTOM of the transcript,
which is exactly where the reader is not. Measured on a real run: 59 steps
while the owner watched the first 14. The count goes on the one control that is
on screen. Not a live region - the transcript already is one, so a screen
reader hears every row arrive; this is for the eye.

A ROW COULD BE CUT OFF AND HAVE NO WAY TO OPEN IT. The decision "this row is
short" counted the characters of the RESULT, while the row also carries the
verb and the argument, in a track the stylesheet sizes: measured on the live
page, 266px on some rows and 376 on others, against the 416 the comment
assumed. So a row could be ellipsised AND have had its chevron removed for
being short, its text reachable only by resting a pointer on it - which is no
path at all from a keyboard or a touchscreen. Measured on a real transcript of
82 rows: 39 had no chevron, 29 were cut, THIRTEEN were both.

The same defect is recorded in this file's history at 120 characters, where the
fix was to lower the number. Lowering it reduced the count and could not remove
it, because the criterion is wrong in KIND: a count in characters standing in
for a fit in pixels. The row is asked the same question the eye asks.

And the reads are batched, which is why this is not a measurement per row:
reading scrollWidth flushes layout and a row is appended just before, so
measuring inside land would force one full layout per row - which a replay of a
long transcript pays all at once on load. Every read happens first and every
write after, so a burst of two hundred rows costs one layout instead of two
hundred.

Suite 606 green. Eight known-bad inputs, eight killed: the row counted in
characters again, the batch measuring nothing, a row with a line break put on
one line, the press asking for an animation, the press landing short, the
button never saying how much is behind, the press leaving the count standing,
and arriving at the bottom not clearing it.

And the gate that exists for it caught me mid-change: slicing the old handler
out left its second line behind, and test_the_whole_script_parses went red with
the exact sentence it carries - a browser runs none of it and the page renders
dead.

Don't miss a new AIHawk release

NewReleases is sending notifications on new releases.