[aywrite]

The rest of king safety, first half: the count. For each side, four counts of how many squares of the enemy king's ring (the eight squares a king attacks from its square) its knights, bishops, rooks and queens attack, over the real occupancy. A slider stops at the first piece of either colour and counts that square if it is in the ring. A square two pieces attack counts twice. Pawns and kings carry no column: the storm already reads the pawns, and a king bearing on the other king's ring is the opposition. Folded white less black against four packed weight pairs through the existing taper, the way mobility folds.

All four weights are zero in this commit, so the bench is 3868987 and every pin is unchanged. The count is not folded away by the compiler at zero weight: measured, it cost 3.2% (mean) to 4.0% (best) of nps against a build with the summand removed, over an identical tree. So the summand sits behind a SCORED const derived from the weights, mobility's pattern, and the fit commit turns it on with no edit. speed.sh reads -0.1% median, +0.2% fastest against master over 21 interleaved rounds at a 5.6% spread.

The term is uncached. It reads every piece of one side, so its key is the position, and the mobility cost record measured that cache at 1.59% fewer instructions and about 1% slower on the clock.

Fourteen hand counts pin the definition (one per kind, a friendly and an enemy blocker, two attackers of different kinds and two of one kind, an attacker inside the ring, a pinned attacker, a corner king, a centre king on a defended square, a pawn and a king that must not count, two bare kings), plus the ring's size on every square, a mirrored reading, a fold test, and two tuner tests. The tuner lays the four columns out from the TERMS table, prints them in the layout line, and scripts/tune.py prices them at 2, 3, 4 and 6 with a hold flag.

Release tests 607 to 614, python 215 to 218. The fit, on a fresh sealed group, is the next commit.

🤖 Generated with Claude Code

[aywrite]

Review round 1, folded into 7cdceae.

A second agent rebuilt both sides in its own build directory: 3868987 on both, all eighteen bench rows identical in every column but time, 607 to 613 release tests at the time, clippy and fmt clean. It re-derived all fourteen hand counts from the definition before reading the commit's numbers and every one agreed. It ran nine mutations of the count against the suite.

Findings, one behavioural on the clock and the rest guards:

• the count was not folded away at zero weight: 3.2% mean and 4.0% best nps against a control build with the summand removed, over 21 interleaved runs on an identical tree; the commit had claimed the fold. Fixed with a SCORED const derived from the weights gating the summand, mobility's pattern, and measured again: -0.1% at a 5.6% spread
• two of the nine mutations survived: pawns counted into a column, and a union per kind in place of a count per piece. Both are pinned now, by a pawn on c6 covering d7 and two rooks on a7 and h7 reading six
• one mirrored row compared the side with no pieces on both boards, so it asserted zero against zero; the fens were in the wrong order, and a guard now fails a row counted from an empty side
• a retained sentence said the tuner's identity would catch a term dropped from the sum; at zero weight it cannot, and the sentence says so now
• the python pricing tests covered three blocks and not the fourth; the fourth has one, and the pawn structure test's range stops at the block after it
• the commit body called all four bounds exact; a bishop shows at most two and a queen five, so three and six are given with a square in hand
• ARCHITECTURE.md still counted three leaf terms; "the other two leaf terms" in the new file were three; the same clause twice in one file; four ragged lines in INSTRUMENTS.md

Every one of the nine mutations is caught after the fold, and a non-zero weight moves the bench to 3937024 and flips SCORED. Airgap and trailers checked.

[github-actions]

Speed against 81093868

Both sides built and run on this runner in this job, the way
scripts/speed.sh measures a perf commit. The change is between
medians, and the spread beside it is what the change has to be
read against. The node counts are the search's: they move when
the search does, and a speed change leaves them alone.

round     base nps  candidate nps
    1      7862596        8099571
    2      8070629        8101657
    3      7920056        7966993
    4      8004905        7965877
    5      8118402        7818725
    6      8007688        7913721
    7      7887167        7911310
    8      8019323        8000469
    9      8000171        8006297

             nodes    time  median nps  fastest nps
base       3868987  0.48 s     8004905      8118402
candidate  3868987  0.49 s     7966993      8101657
change                           -0.5%        -0.2%

the change is inside the spread, so the medians make no claim; the
fastest column is the steadier comparison when the machine was not
quiet

Speed: -0.5% (bench nps, 9 interleaved rounds vs 81093868, spread 3.6%)