docs(ab): hw4 evidence fix round 1 - bit-write gap provenance, README/CLI/fixture docs, libplctag-deletion gap

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe
This commit is contained in:
Joseph Doherty
2026-10-09 04:12:53 -04:00
parent 14ec145487
commit 9e894decb0
7 changed files with 37 additions and 31 deletions
@@ -193,6 +193,7 @@ public sealed class EvidenceTests
$"max={(ids.Count > 0 ? ids.Max() : 0)} more={more} ascending={strictly} ids=[{sample}]");
}
Log($"Non-ascending pages: {nonAscending}");
Log(nonAscending == 0 ? "RESULT: every listing page strictly ascending." : $"RESULT: {nonAscending} NON-ASCENDING page(s) observed.");
pages.ShouldNotBeEmpty();
opens.ShouldBe(1);
}
@@ -121,11 +121,17 @@ trip cleanly across SLC500, MicroLogix, and PLC-5 modes.
### Bit-file writes on ab_server
`B3:0/5`-style bit-in-boolean writes currently surface `0x803D0000`
against `ab_server --plc=SLC500`; bit reads work. Non-blocking for the
smoke suite (which targets N-file Int16 + F-file float reads), but
bit-write fidelity isn't simulator-verified — route operator-critical
bit writes to real hardware or RSEmulate 500 until upstream resolves.
Originally (May 2026, libplctag only, before the native transport) a `B3:0/5`
bit write surfaced `0x803D0000` against `ab_server --plc=SLC500`. **That does
not reproduce any more** (2026-10-09): `AbLegacyBitWriteTests` writes `B3:0`,
sets bit 5 and clears bit 3 and asserts the whole word each time, and passes
on SLC500 and MicroLogix on both libplctag and native, and on PLC-5 with
libplctag. The cause of the original failure was never determined (the
driver's parent-word read-modify-write and ab_server's PCCC handlers are
both unchanged in shape, so an older libplctag/driver path is the likely
difference). PLC-5 on the native transport returns `0x803D0000`
(`BadNotSupported`) for a different reason: all native PLC-5 writes are
refused before the wire (#571); the test pins that.
### Other known gaps (unchanged from ab_server)