A hand-off's derived withdrawal read whichever stewardship `stewardships_of`
listed first. While the withdrawal is being derived the hand-off's own is
excluded from what stands, so two assignments are in force at once: the one
this hand-off withdrew, and whatever stewards the repo now. Key order does not
tell them apart -- once a repo has changed hands ten times, `n11` sorts before
`n2` -- so replaying an old hand-off derived a second withdrawal of a standing
assignment and died on the identity collision instead of answering with its
first receipt. `stewardship_of` now takes the stewardship whose withdrawal
already carries this hand-off's key, the same content match the ruling's answer
and the receiving side's assignment already use, and falls back to the one in
force. The comment claiming at most one is ever in force said the opposite of
what the exclusion does; it is gone.
`later_than`'s resolution arm is deleted. Nothing could reach it: the Q19 cap
refuses a withdrawal whose subject is a resolution of a resolution before the
reinstatement rule asks what stands later, so the arm was dead and the entry
Soul wrote against it could not fail. Dead code with a test that cannot reach
it is what subtraction is for -- an arm no caller enters is a rule nobody can
break and nobody can rely on, and leaving it would have bought a green mutation
line for a branch the machine never runs. The two doc sentences that named the
resolution scope go with it.
Four fixtures close gaps where the code was right and the suite could not tell
it from something weaker: a ruling answering a reopened question takes the next
sequence rather than reproducing the withdrawn answer's; a cut spec's revisions
are read within its own cut, so cut B's second does not block reinstating cut
A's first; `later_in_force` counts only what stands, and reads the batch, so an
assignment derived beside a withdrawal still blocks it.
Entries H62-H67 pin all six. H1-H67 killed by their own tests, M0 green;
46 tests pass with no warnings; `cargo check --workspace` clean.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Both anchored on the `latest_resolution`/`latest_stewardship` call `derive`
no longer makes, so the harness stopped at H45 with no verdict rather than
running. The rule each entry states is unchanged -- a derived record takes
the next sequence of its scope, not always the first -- so each moves to the
line that now decides it and keeps its killer.
H1-H61 all killed, M0 green.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
H52-H61, each restoring one permissiveness the follow-up closed and naming
the test that must fail while it is applied.
H52-H54 revert the three derivation sites to an unconditional `latest + 1`,
one per derived kind, killed by the two replay tests. H55 and H56 drop the
reinstatement check against the retaken repo and the superseded revision.
H57 and H58 let each sequence rule accept a gap, which only a test whose
sequence is above the expected one can tell from the rule. H59 reads the Q19
cap's subject from the image alone, H60 `latest_resolution` from the image
alone, and H61 sets the hand-off's derived withdrawal to sequence 1 -- the
three Soul's second pass could restore with the suite still green.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Two tests for the rules the last commit landed.
`a_withdrawn_resolution_reopens_its_subject_and_stays_readable` withdraws a
closure, admits the next one at `n2`, reads the first back with its outcome
intact, refuses a third while `n2` stands, refuses the withdrawal of the
withdrawal, and has a ruling answer the reopened question -- the derived
resolution lands at `n2`, not `n1`.
`a_repo_is_stewarded_once_at_a_time_and_again_after_a_transfer` refuses a
second assignment while the first stands and a second claiming the taken
sequence, hands the repo away, finds nothing stewarding it, hands it back and
gets `n2` with the second `handed_on`, the first still readable by key.
Entries H40-H46 carry the mutants: the two sequence rules, the recursive
in-force, `AlreadyStewarded`, the Q19 cap, and `derive`'s two sequences.
Then the six places Soul found the code right and the suite blind, each a
fixture and an entry (H47-H51): a handed-away repo is not stewarded, so
`stewardship_of`'s in-force half is pinned; a document two batch documents
cite is pinned once rather than cancelled; what a derived write cites in the
image is pinned, which is H32's surviving half; a finding may cite the
vocabulary of the target landing beside it; `Answered` coherence is checked
against a ruling in the image as against one in the batch; a branch differing
only in case is a mismatch.
H32 is re-anchored rather than left to rot. Its A4 half is unreachable now: a
derived write takes the sequence after the batch's own records, so a derived
identity cannot collide with one the batch holds. What survives is that
derived writes are validated, staged and resolved like any other, and the
transfer test's strong read is what fails when they are not.
README stops claiming the two stub crates do anything.
H1-H51 all killed, M0 green. 33 tests, 0 warnings; `cargo check --workspace`
clean; `git diff --stat 4094e68 -- .voidbot` empty.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Soul's pass found the suite claimed more than it proved: H1-H20 killed
twenty mutations, and nineteen further permissivenesses could be restored
with every test still green. A rule no test reaches is a rule the next
pass may delete by accident.
Two of them were about the receipt's atomicity and its reach, and needed
new machinery. A store in `receipt.rs`'s tests records the replacement set
of every swap it is asked for, which lets one test say what no assertion
over the resulting image could: a commit is one compare-and-swap, and the
documents and their receipt go in it together. Splitting the receipt into
a second swap now fails. Separately, a batch citing three image documents
is pinned against all three, so truncating the strong reads to the first
of them fails.
The rest are one fixture apiece, each closing a row the per-kind rules
already held: stewardship looked up in image as well as batch; the cut
report's repo as well as its branch; a promise measured by the claim that
names that label; the invariant vocabulary taken from the in-force target
and not a superseded one; a question that is answered or withdrawn but
never superseded, and a target never answered; the derived stewardship
dated by the hand-off; derived writes passing A3-A7, so a derived identity
the batch already holds is A4's refusal and not a store error; A4 and A2
themselves; a question's two distinct options and its recommendation among
them; unique labels on a question's options and a target's invariants; a
finding's locations; and an `Answered` naming the ruling that actually
answers its subject.
`tools/eureka-cut8-mutations.psd1` grows to H1-H39. H21 and H22 pin the
opener's epoch key and count, H23 `EmptyRepos`; the rest are Soul's own
survivors, adopted as entries so the thing that found them is the thing
that guards them.
Harness: M0 green at 31 tests, H1-H39 all killed by their own test.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Cut 8, Huginn half, commit 4 of 4: `tools/eureka-cut8-mutations.psd1`,
entries H1-H20, each the exact source change that restores one
permissiveness this cut closed and the one test that must fail while it
is applied. The suite runs through Epiphany's `tools/eureka-mutations.ps1`
with `-Repo F:\Projects\Huginn`; Huginn holds only the entries.
H5 is a four-edit entry: `Mind::open` is switched to the transient redb
store, which needs a `MindStore` impl the live crate deliberately lacks,
so the entry supplies it in `store.rs`. That makes `store.rs` a fourth
harness target beyond the three the spec names; the file's header says
so. H7 moves the replay check above the per-kind rules rather than above
A7, since the digest it looks up needs A7's strong reads to exist.
Run 2026-09-16 against `0bd7133`: M0 green with 26 tests, every entry
killed by its named test, every target restored byte for byte.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
