vendor tool that covers what the gate checks
They ruled on all seven items the same day. Two were actionable here.
F28 RULED: points. Modes.csv MODE_COOP clarified upstream to say
"penalties apply to points, not card count"; mastery is now
total - blame - denied. A recorded scenario went red on it --
gr-e02-shared-ground pinned 0 (2 claimed CARDS - 1 - 1) and now expects
2 (4 POINTS - 1 - 1). The number moved because the rule was decided, not
because the engine drifted, and the scenario records both rulings; its
schema has no field for a second one, so both live in ruled_note with
`ruled` carrying the LATEST date.
F29 RULED not-intended and APPLIED upstream: SCN_02's suits re-tuned the
same day. The characterisation test is how we found out -- it pinned the
duplication, went red on the re-tune, and that red WAS the notification.
It now asserts every pair distinct, the stronger statement the
duplication had made unavailable. SCN_02 re-measures at 73 at 2p, not
67: its own board now.
F26/F30 ruled and recorded. F30's ruling incidentally confirms our
reading -- they name priority-2's suit as the first lever, which is the
difference we identified without having measured causation.
vendor-editions grew twice, both times because it covered less than the
gate it exists to satisfy:
- It refused to touch ground-darvo-r0/ on the reasoning that the
baseline is "a separate record". That was wrong within the hour:
ground-game clarified Modes.csv and `make vendor` reported a clean
sync while edition-check went red. A sync tool that covers less than
its check reports success into a red gate.
- Its two-block rewrite DETECTED which fence held which set and
preserved the arrangement -- faithfully preserving a swap an earlier
write had introduced, leaving each fence under a heading describing
the other. edition-check reads every sha256 line flat and passed
throughout: a document can be self-consistently wrong and green.
Order is now asserted, with a control that goes red on a swap.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Five things worth their time, four of them asks rather than statements:
F29 SCN_01 and SCN_02 are the SAME BOARD -- identical suit and value at
every priority, every cell matching exactly. Not called a defect (a
reskin is legitimate) but "four scenarios" is three boards. Asked
whether it is intended.
F30 SCN_04 is materially harder at 2p: 52/100 against 67 and 73, with
every other parameter held by the edition itself -- same deal shape,
same 6 available points, same threshold, same starting Stress. The lone
difference is that it is the only 2p deal needing two of one suit.
Causation explicitly NOT claimed; the falsifier is stated. Sensitivity:
at 4p SCN_04 is 97 against 94/99, so it is not the hard board there.
The modes finding, corrected in their favour: we previously reported the
three modes produced identical play. That was OUR INSTRUMENT, not their
game -- the bot never read the Mode card. With a mode-aware bot, group
success is unchanged in 34 of 36 cells but coalition size moves by half
again at 4p. So the modes decide the distribution of the win and the
threshold decides survival independently of it.
F28 (mastery counts cards where the shared score counts points) and F26
(a package that adds a FILE is invisible to a consumer) promoted to
reported -- both need their ruling, neither changed on our side.
F17 and F26 move raised -> reported now that they are in a delivered
report.
The register crossed the ~400-line loadability limit, so prose for
CLOSED findings moved to FindingRegister-closed.md. The rows are
untouched and `make design` still reads one file -- ADR-0012 D5's
reasoning about mixing open and closed applies to files too.
Report left UNCOMMITTED in ground-game: their tree has live uncommitted
work from their own agent.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
