Remove Gittensor impact badges from README - #7001
Merged
Merged
Conversation
Removed Gittensor contributor impact section from README.
github-actions
Bot
added
the
needs-maintainer
Contributor
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe README removes the linked Gittensor contributor-impact badge block. No exported or public entities change. ChangesREADME documentation
Estimated code review effort: 1 (Trivial) | ~2 minutes ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
4 tasks
lgray
added a commit
to lgray/phase
that referenced
this pull request
Aug 5, 2026
…ated The rebase onto upstream `b654513cb` (phase-rs#6996, phase-rs#6999, phase-rs#6998, phase-rs#7001, phase-rs#6997, phase-rs#6946) resolved the census row's conflict to upstream's three `effects/mod.rs` literals, which are correct for the upstream tree but not for this branch replayed on top of it. Re-derived from the row's own failure output — never predicted by arithmetic — and re-pinned: `:6065/:6142/:9324 ⇒ :6175/:6252/:9456` The shift is NOT uniform (`+110/+110/+132`), and the asymmetry is the measurement: C1's `upfront_optional_gate` authority is one 110-line hunk above all three producers, and `resolve_chain_body` takes a further `+22` from two hunks inside itself and above its own gate (the `optional_for` coupling note, and adoption A replacing the inline conjunct chain with the authority call plus its `debug_assert!`). The file's whole-file delta is also `+132`, so nothing lands below the third producer, and `6065+110`, `6142+110`, `9324+132` equal the observed coordinates exactly. Identity re-established rather than assumed. Each producer at its new coordinate is sha256-identical to `b654513cb:effects/mod.rs` at its old one and to the pre-rebase tip `117baa6a1` at `:6109/:6186/:9183`, and each is still inside the enclosing function this row NAMES — `drive_sequential_repeated_optional_payment`, `resolve_repeated_optional_payment_choice`, `resolve_chain_body` — which is stronger evidence than the coordinate. The diff instrument discriminates: in the new tree the three old coordinates hold a `may_trigger_auto_choice` lookup, a blank line, and a bare `//`. `engine.rs:11549` was re-derived too, not carried over, and is UNMOVED: upstream's six commits net ZERO above it (`:11420` in both the old base `dcb8f3808` and the new base `b654513cb`), so this branch's own `+95`/`+34` still land it on `:11549`, byte-identical and still inside `begin_pending_trigger_target_selection`. `scoped_library_search.rs:452` is unmoved as well. Two entries holding still while three move is the set-preservation evidence: the row's first two asserts fired GREEN on the run that caught this, so the total stays 37 and the partition stays 5/7/25 — no producer was gained or lost. Assisted-by: ClaudeCode:claude-opus-5
matthewevans
pushed a commit
to JacobWoodson/phase
that referenced
this pull request
Aug 5, 2026
phase-rs#7005) * fix(engine): announce the entries a forced-window answer places on the stack CR 732.2a's ring sampler had exactly one site: `pass_priority_once_with_pipeline`, which fires only at an active-player `Priority` settle. Any stack entry that resolves ACROSS a forced pre-priority window — a CR 608.2b `TriggerTargetSelection`, a CR 603.5 `OptionalEffectChoice`, a CR 603.3b `OrderTriggers` — was therefore never present in two consecutive retained frames, so `certified_period_touch`'s announced set ("entries in a frame's stack absent from the previous frame's") could not see it and `bounded_cycle_pin_slots_for_window` could not publish its choice. The shortcut then described a sequence with unpublished per-iteration choices in it. This adds the SECOND sampling site, in `apply_action`, keyed on the forced-window flag captured BEFORE the reducer consumed it. Its conjuncts are the settle sampler's, plus a non-shrinking-stack guard measured against the pre-action depth. Consequences carried in this commit rather than left to be discovered: * the structural pin `arc_as_ptr_beat_identity_is_the_sample_not_one_of_its_halves` moves 2 -> 3 `as *const` reads (the shared per-beat `before` plus an `after` read in each arm that can advance the ring), so a re-basing onto a field address still flips it; * two doc comments claiming `victim_slot` is "empty on every trajectory that offers today" are FALSIFIED by the widening and are replaced, not softened — a `Targets` declaration is announced now, so `worst_seat_life_loss` reaches `elimination_bounds` in production; * B5f rows that consequence two-sided on the user's own MODE1 capture (tracked here as `f4_user_mode1_no_offer_4p.json.gz`, 860,451 B, derived `jq -c '{gameState}' | gzip -9 -n` from the 20.5 MB envelope): with P1 seeded at 7 and 6 the offer FIRES with `max_iterations == 1`; at 5 and 4 the drive reaches the same beat, raises nothing, and the typed verdict is `NoNarrowedLegalCount`. The arms are ONE life point apart, which is what makes the row about the divisor rather than about the board. Landing FIRST of the five commits is load-bearing: relief without the widening turns a silent no-offer into a treadmill that offers and commits nothing. Assisted-by: ClaudeCode:claude-opus-5 * refactor(engine): one authority for a loop-shortcut period boundary `drive_one_shortcut_cycle` delimits a committed repetition two ways: board recurrence, and — for the certification basis that consults no board predicate at all — the published `frames_per_period` count. The frame-count arm existed at exactly one beat kind, the active-player settle, because that was the ring's only sampling site. With the answer-beat sampler in place that premise is gone: a period whose extra frames are recorded while a player answers a forced pre-priority window would never reach `k`, so `frames_per_period` becomes unreachable on precisely the boards the widening was for, and such a drive can only end at its runaway beat cap having committed nothing. The injector arm therefore advances the same counter, under the same `Arc`-identity frame detector the settle arm uses. Both arms now ask ONE function. `published_period_elapsed(frames_this_cycle, frames_per_period)` carries the two properties neither call site can state: `None` NEVER elapses (an offer that published no signature must not have one invented for it, because ending a cycle early commits a fraction of the published delta — the conditional action CR 732.2a forbids), and the comparison is `>=` rather than `==` (one beat may retain more than one frame, and an `==` would drive past its own boundary). Two regression rows, one on each surface: * `published_period_elapsed_is_total_over_the_axes_that_delimit_a_cycle` asserts the whole truth table, including the `k - 1` and `k + 1` arms that discriminate the off-by-one and the `>=`/`==` choice — the anti-vacuity control the structural row cannot supply; * `the_period_delimiter_has_one_authority_and_both_frame_recording_arms_ask_it` censuses `drive_one_shortcut_cycle`'s extent with the tree's own comment-excluding extractor: exactly two delimiter calls, exactly two counter advances, and ZERO inlined raw comparisons, with a proven-live instrument on both sides of the zero census. Also restores `drive_one_shortcut_cycle`'s doc block, which the delimiter extraction had silently re-attached to the new function, and corrects its "the single `record_loop_detect_sample` call site" sentence — there are two sampling sites now. Assisted-by: ClaudeCode:claude-opus-5 * fix(engine): discharge a loop's replacement obligations against the live board Conjunct (6) classifies each announced stack entry on its CARRYING FRAME — a retained ring sample, and therefore a board from the past. It then discharged the resulting `FreeUnlessReplacements` obligation against that same frame, which answers the wrong question: a shortcut is a claim about the FUTURE, and every remaining repetition resolves under the board that exists NOW. A replacement definition that entered the battlefield after the sample was taken is invisible to the frame-side check, so the described sequence could contain exactly the CR 616.1 resolution-time choice CR 732.2a forbids. The gate now discharges a second time against `state`, guarded by `!ptr::eq(*frame, state)` — a de-duplication, not an exemption: when the pair is carried by `current` itself the first call already ran on that very board. Two rows, each with its own paired positive: * `n3_a_replacement_installed_after_the_frame_was_captured_refuses_certification` builds a ring whose frames are all cloned BEFORE the definition is installed, so the def exists on the live board and nowhere else, and runs four arms — no def (certifies), live-only OPTIONAL (refused, the arm this change exists for), live-only MANDATORY (certifies, which keys the previous arm to optionality rather than to "a definition exists"), and present-everywhere OPTIONAL (refused, proving the frame-side discharge still does its own job so this is an ADDED refusal, not a relocated one). `announced_from_retained_sample` runs on every arm as the reach-guard that the pair is carried by a frame that is not `current`. * `n3_b_a_live_carried_pair_is_still_discharged_by_the_first_call` exhibits the short-circuited shape and shows the optional definition is still refused there. CR anchors corrected in the same change, because they are about this seam. CR 614.1a is "effects that use the word instead" — a sub-rule cited for its parent's job. The prompt-cause authority in `replacement.rs` classifies EVERY applicable replacement, including skips, enters-with, turned-face-up and virtual candidates that carry no `ReplacementDefinition` at all, so its anchor is the definitional head CR 614.1; and what makes an optional replacement disqualify a shortcut is CR 732.2a's ban on conditional actions, not CR 614.1a. Both `replacement.rs` sites and four r9 sites now read `CR 732.2a + CR 614.1`, in that order. CR 616.1 stays on the two-or-more ORDERING branch, where it belongs. Assisted-by: ClaudeCode:claude-opus-5 * fix(engine): one authority for whether a "may" is already answered, and answer the shortcut's gate with it Three places answered "does this ability open ONE up-front optional gate, and to whom, under which key?" — production's own branch in `resolve_chain_body`, the loop-shortcut mint's guard (b), and `analysis::resource::auto_may_answer_for`. The latter two asked the same four predicates and OMITTED two conjuncts the first has: `optional_for` and the CR 608.2d feasibility probe. Measured, that made them return a different answer on two ability shapes, and each was defended only incidentally — the fan-out case by a disjunct in `resolution_prompt.rs` answering a different question, and the infeasible case by membership of a fail-closed list from which three variants have already been promoted out. `effects::upfront_optional_gate` is now the assembler, and production's own branch IS that function rather than a fourth copy of it. `stored_may_answer` is its consumer half. `OptionalFeasibility::{Known, Probe}` exists because a naive adoption would have made production probe TWICE: `resolve_chain_body` has already run `optional_effect_is_infeasible` for the `CastFromZone` decline early-return that precedes the gate, and that arm clones the whole `GameState` per bound object to run a dry-run cast. Adoption A hands its answer over as `Known`; every other caller passes `Probe`, which the authority evaluates LAST so the clone-bearing arm is reached only for `optional AND NOT optional_for AND NOT repeat` entries. It is deliberately not charged against `PROBE_BUDGET`: that counter bounds CR 732.2a certification asks at the verdict door, and mixing wall-clock cost into it would re-base every metered row's pinned spend. Guard (b) adopting the authority is a BEHAVIOUR CHANGE and it is rules-correct in the fail-closed direction. It now withholds the `MayChoice` slot for an `optional_for` ability — CR 608.2d + CR 101.4 make that an APNAP cascade of up to one window per living player, and one published slot standing for N prompts is the cardinality defect group (c) already argues against — and for an infeasible optional, which opens no window at all, so a slot for it is a pin the gate can never spend. Direction: strictly FEWER offers, never more. N0 rides on the same authority: gate (6) now takes relief from a stored auto-choice as well as from a published pin, and the two bases are disjoint by construction because guard (b) publishes a slot only for a may with NO stored answer. Reading an auto-answered may's slotless mint as "unspecified" was the defect. Only `Accept` is relieved — a stored `Decline` is equally prompt-free but produces the OPPOSITE board, so its optional-cleared residual would describe events the shortcut never proposes. Rows, each with its own paired positive: * `a5_a_stored_accept_relieves_gate_six_and_a_stored_decline_does_not` — one board, one key, one value different; the arm the user's MODE1 capture rides on. * `f2a_the_upfront_gate_authority_answers_the_two_shapes_the_third_copy_omitted` — every arm seeds a stored `Accept` under exactly the key the old copy built, so an omitted conjunct is a WRONG answer rather than an absent one. Includes the feasibility control (the same `RemoveCounter` ability on a board ONE counter different) and the pair that proves `Known` overrides the probe instead of re-running it. * `f2b_guard_b_withholds_a_pin_the_cr_603_5_gate_can_never_spend` — deliberately UNSEEDED, so guard (b)'s store conjunct is vacuously true on every arm and the only thing that can move `may` is the axis under test. A seeded variant is rejected: it cannot fail for the reason the row exists. * `f2c_the_cr_603_5_conjunct_set_has_one_production_assembler` — MEASURED per-predicate production call-site counts 2/2/2/1/2, plus the stronger statement that ZERO production consumers live outside `game/effects/`, with a proven-live instrument on the zero census. The three surviving non-authority sites select a DRIVER rather than opening an up-front window, so folding them in would be wrong, not cleaner — and the guarantee is stated honestly: an inline re-derivation from `ability.repeat_for` is NOT caught, and no census over these five tokens can catch it. `cargo clippy -p phase-engine --all-targets -- -D warnings` is clean under the shipped enum, with zero `is never constructed` (both variants are constructed on production paths, and F2a exercises `Probe` to opposite outcomes). Assisted-by: ClaudeCode:claude-opus-5 * test(engine): re-derive every row whose premise was the sampler's blind spot, and pin both user captures The answer-beat sampling site (C4) widened what a CR 732.2a offer can publish, and several rows had encoded the OLD blind spot as if it were a property of the board. Each is re-derived from measurement rather than relaxed, and both of the user's own captures are tracked and driven end to end. THE FIX BAR. `a1_the_users_accept_committed_nothing_board_now_commits_on_every_axis` drives the user's MODE2 capture — the board where the offer fired, the declaration was accepted, and the drive then committed nothing and re-offered. It now publishes all three per-iteration choices and the accepted `Fixed(n)` grant commits EXACTLY n repetitions of the offer's own published per-cycle signature on life and library, with counters and tokens non-zero at n=1 and exactly 3x at n=3. Revert-probe run: with the answer-beat site ablated every axis collapses to 0, reproducing the captured symptom. `m1_...` is its one-field-apart sibling on MODE1 (a STORED CR 603.5 answer, so guard (b) withholds Sue's slot and the auto-answer relief discharges gate (6) instead). `--lib` rows re-keyed to production's own walk. `newest_item4_window` consumes `game::engine::candidate_windows`, so R21(b-placement-B)'s window IS production's rather than a hard-coded `len - 2` that silently asserted `span == 1`; its reach-guard now states what it needs (no denied answer; a gate that ASKED must have completed) with the load-bearing exemption equality byte-identical. R16(ii-b) searches its real construction requirement (`meter.spent > 0`, never `denied`, which would assert itself) and ships its own revert-probe as a `RaisedTwiceLinks` positive control. The CR 603.5 prompt census is re-pinned from the failure's own left side, every producer sha256-identical at its new coordinate and still inside the function the row names, and its authority count is made comment-insensitive so prose cannot trip a call-site pin. Attribution repairs: `r2` is renamed `r2a` to state what its body now asserts; r1 keeps its over-charge follow-up pointer instead of claiming discharge; the `r5_declare_is_accepted` citation is replaced with the per-caller measurement that actually exists; the r28 empty-schema arm DISCLOSES that its path is now reached by staging rather than naturally; a pre-existing `CR 614.1a` comment that described no rule is corrected to CR 614.1. `ai1_the_bounded_declare_candidate_withdraws_when_the_offer_publishes_a_pin` pins the generator's `Fixed` candidate to the published pin set in both directions on one board, and is deliberately not `#[ignore]`d. Assisted-by: ClaudeCode:claude-opus-5 * docs(engine): replace the four notes C4 falsified, and recover the counter assertion a false premise cost Five ACCEPT-WITH-FIXES findings, plus one sibling swept by the same defect mechanism. `crates/engine/src/` is COMMENT-ONLY this round — proved by `git diff -U0 crates/engine/src/` having no non-comment +/- line — so the only executable change is in the F4 test file. F1. Four docs still asserted the pre-C4 premise that `record_loop_detect_sample` has ONE call site, and this branch's own policy is to REPLACE a falsified note rather than soften it. The measured truth is TWO production sites, both after `run_post_action_pipeline` (CR 603.3): the settle sampler in `pass_priority_once_with_pipeline` and the forced-window answer site in `apply_action`. Rewritten at the fn doc and the `loop_detect_ring` field doc (`game_state.rs`), at `frames_per_period` (`resource.rs` — the justification C2 had already repaired in code), and at `ring_delta_signature`, whose homogeneity argument now rests on the `Priority{active_player}` conjunct the two sites SHARE rather than on there being one site. F1e (swept sibling). `drive_one_shortcut_cycle`'s "the frame counter is advanced here and nowhere else" was falsified on this same branch by the forced-window ANSWER arm's own advance. Both arms key the advance on the ring's back allocation changing, which is what keeps drive and mint one-to-one. F2. The second site's comment claimed "the same conjuncts as the settle sampler, PLUS the window flag". Measured, the sets are the same size one member apart: `answering_forced_window` REPLACES `resolved_this_beat`, and the settle site's `else { ring.clear() }` has no counterpart here. The comment now says that, names the consequence (an answer that resolves nothing but leaves the stack non-shrinking records a duplicate frame), and says why it is acceptable — `ring_delta_signature` refuses a zero smallest-period delta, and mint/drive are symmetric because `inject_pinned_answer`'s arms all dispatch `apply_action`. It also documents the latent ordering asymmetry: this site records BEFORE `state.waiting_for = wf` while the settle sampler records after `sync_waiting_for`, and `GameState::eq` compares both `waiting_for` and `priority_player` while `normalize_for_loop` neutralizes neither. Latent, not live: a `debug_assert_eq!` census reported 0 failures across 18,486 lib and 4,487 integration rows, with a `debug_assert!(false)` positive control that fired on the A1 board. Deliberately NOT reordered — that would be a behavioural change for a non-live defect. F3. The fix bar's life and library equalities had no anti-vacuity guard, so an all-zero certificate would satisfy `moved == rate * n` on a board that never moved. Added, in the existing `assert_axis_scales` idiom. F4. The counter assertion had been weakened on a false premise. Measured, the published vector is `counters {(Plus1Plus1, Creature): 2}` — non-zero and state-readable; only `tokens_created: 0` is event-fed. The real obstacle was the accessor: `commit_axes` reads ONE object's counters against an AGGREGATE key. Re-cut against `ResourceVector::snapshot`/`delta`, the accessor the certificate is minted from, plus a "nothing unpublished may move" arm. The aggregate moves 2 at n=1 and 6 at n=3, i.e. exactly 2n. The token axis keeps the scaling arm alone, now for its real measured reason. F5. `has_frozen_window`'s residual was declared as "four authored-ring rows". Measured: two call sites, and NEITHER is an authored ring — both drive the real tracked dumps. Overstated in count, understated in kind. The disclosure now names both rows and the loud floor that lets them keep a hard-coded `span == 1`. The CR 603.5 prompt census went red on F2's line drift and was re-pinned by its own protocol, not by matching the tree: `engine.rs:11515 => :11549`, +34 which is engine.rs's entire (comment-only) delta above the producer, the line sha256-identical at the new coordinate and still inside `begin_pending_trigger_target_selection`; total 37 and partition 5/7/25 unchanged. Every new assertion and guard is proven to flip. Ablating the answer-beat sampling site fails the library equality at `left: 0 / right: -1` (the prior probe's signature) and, with the seat loop bypassed so control reaches it, the recovered counter equality at `left: 0 / right: 2`. Zeroing each published rate in turn fires each guard alone. All five are typed assertion failures, not harness crashes. lib 18487 passed / 0 failed, integration 4487 passed / 0 failed / 2 ignored, clippy --workspace --all-targets -D warnings exit 0. Assisted-by: ClaudeCode:claude-opus-5 * test(engine): re-derive the CR 603.5 producer pins the rebase invalidated The rebase onto upstream `b654513cb` (phase-rs#6996, phase-rs#6999, phase-rs#6998, phase-rs#7001, phase-rs#6997, phase-rs#6946) resolved the census row's conflict to upstream's three `effects/mod.rs` literals, which are correct for the upstream tree but not for this branch replayed on top of it. Re-derived from the row's own failure output — never predicted by arithmetic — and re-pinned: `:6065/:6142/:9324 ⇒ :6175/:6252/:9456` The shift is NOT uniform (`+110/+110/+132`), and the asymmetry is the measurement: C1's `upfront_optional_gate` authority is one 110-line hunk above all three producers, and `resolve_chain_body` takes a further `+22` from two hunks inside itself and above its own gate (the `optional_for` coupling note, and adoption A replacing the inline conjunct chain with the authority call plus its `debug_assert!`). The file's whole-file delta is also `+132`, so nothing lands below the third producer, and `6065+110`, `6142+110`, `9324+132` equal the observed coordinates exactly. Identity re-established rather than assumed. Each producer at its new coordinate is sha256-identical to `b654513cb:effects/mod.rs` at its old one and to the pre-rebase tip `117baa6a1` at `:6109/:6186/:9183`, and each is still inside the enclosing function this row NAMES — `drive_sequential_repeated_optional_payment`, `resolve_repeated_optional_payment_choice`, `resolve_chain_body` — which is stronger evidence than the coordinate. The diff instrument discriminates: in the new tree the three old coordinates hold a `may_trigger_auto_choice` lookup, a blank line, and a bare `//`. `engine.rs:11549` was re-derived too, not carried over, and is UNMOVED: upstream's six commits net ZERO above it (`:11420` in both the old base `dcb8f3808` and the new base `b654513cb`), so this branch's own `+95`/`+34` still land it on `:11549`, byte-identical and still inside `begin_pending_trigger_target_selection`. `scoped_library_search.rs:452` is unmoved as well. Two entries holding still while three move is the set-preservation evidence: the row's first two asserts fired GREEN on the run that caught this, so the total stays 37 and the partition stays 5/7/25 — no producer was gained or lost. Assisted-by: ClaudeCode:claude-opus-5 * docs(engine): replace every doc claim this branch's own rows falsified, and re-measure the span==1 residual The final review at 7841e1e found three survivors of the F1 falsified-doc class plus one unproven mechanism. A mechanical sweep of the same class found two more the review did not name, both in the test file the previous round never searched. Comment-only; no behaviour. r1's doc said the offer "publishes ONE point and commits ZERO cycles (see r1b and r2)". All three clauses are dead: r1b's own assert_eq! pins THREE points [Sue MayChoice, Reed MayChoice, Torch Targets]; r2a commits exactly n at n=1 and n=3; and `r2` names a row this branch renamed (fn-name diff b654513..HEAD: exactly one name disappeared, r2_an_accepted_declaration_commits_zero_cycles_because_reeds_may_is_unannounced, and zero references to it survive). r1's second paragraph was falsified too and went unreported: the in-tree form is the ADDITIVE one (resource.rs observed_life_loss.max(0) + declared_life_magnitude), not the MAX form, and victim_slot is NON-EMPTY on this board, so the two forms do not coincide. r1b's OWN doc block was the sharpest instance and neither round had caught it — it said "403 and 401 are never announced ... publishes exactly ONE point" while the same function's body asserts three and its message says all four sources are announced. The U6 header's "F4 publishes ONE point, not three" and the Fixed-gate bullet's "F4 publishes one point" are corrected with the reason preserved: the AI still declines, but on the emptiness gate, never on the count. resource.rs:10713 is brought into line with the two siblings this branch already replaced at resource.rs:1062-70 and engine.rs:2257-64, reusing their wording. has_frozen_window's span==1 residual was justified by an unproven mechanism ("both fail LOUD on a half period"). A half period is non-degenerate, so those guards do not fire, and both rows' assertions are span-independent — they would PASS. Re-measured here rather than transcribed: at the beat drive_dump_until(gz, 80, has_frozen_window) selects, dina beat=6 ring=2 and dellian beat=5 ring=2, and candidate_windows yields exactly one candidate (idx=0, span=1, len=2) on each, so &live[len-2..] is the whole ring and span==1 is exact. The residual is restated as "exact today, silent if the sampling rate grows this ring past two". inject_pinned_answer's "arms all dispatch apply_action" (two sites) is corrected for precision: four arms, three dispatch, the fourth Err()s before any frame advance. The mint/drive symmetry conclusion survives and is now stated in the stronger form the code supports. The engine.rs edit is deliberately line-neutral (3 for 3) so the CR 603.5 census pin at engine.rs:11549 does not move; verified still on the OptionalEffectChoice producer and the census row green. --lib: 18501 passed; 0 failed; 6 ignored. --test integration: 4513 passed; 0 failed; 2 ignored. clippy --workspace --all-targets -D warnings: exit 0. Assisted-by: ClaudeCode:claude-opus-5 * fix(engine): correct the CR 608.2d announcer citation, derive r2a's rates from the certificate, and make an unresolvable point source fatal CodeRabbit left four inline findings on phase-rs#7005. Three hold; the fourth's premise does not, and the difference is a measurement rather than an argument. F-A - `UpfrontOptionalGate::prompt_player` cited CR 117.3a ("The active player receives priority at the beginning of most steps and phases..."), which is priority timing. The field names the player who ANNOUNCES the choice, which is CR 608.2d ("...the player announces these while applying the effect."). Both quotes verified against the rules text before the edit. `optional_prompt_player`'s own doc carried the identical wrong citation and is fixed with it. Both edits are line-for-line so the CR 603.5 prompt census keeps its exact pins. F-B - CodeRabbit asked for memoization "if the fixtures produce optional, non-repeat, non-`optional_for` `CastFromZone` entries". They do not. Instrumenting the clone-bearing arm and both `state.clone()` sites, with a thread-local marking the `Probe` path, over a full `--test integration` run (reproduced bit-for-bit across two runs): 16402 raw mint calls => 4573 `Probe`-mode feasibility calls => 0 arm entries and 0 clones on that path. The 59 arm entries and 50 clones that do occur are production's own `Known` path, which pays them once per resolution. The zero's positive control is in-band: `P` and `K` are two labels from the same statement, and `K` returned 59. The memo itself already exists for the other caller - `PeriodVerdicts` is a `(FrameIx, ObjectId)`-keyed compute-on-miss memo whose `published` field IS `entry_publishes_pin_slots`. Recorded the measured number at the seam; added no memoization for a cost of zero. F-C - `(libs_before[0] - libs_after[0]) as i64` subtracted two `usize` before the cast, so the zero-commit regression the row exists to catch aborted on an arithmetic overflow instead of printing the row's own diagnostic. Demonstrated both ways: the old form under the underflow condition panics `attempt to subtract with overflow` with the diagnostic suppressed; the new form fails as `assertion left == right` and prints it. The row also asserted `(i64::from(n), i64::from(n))` - two literals - while its message claimed the published per-cycle delta. Both rates now come from `certificate.per_cycle.delta`, negated because the axes are measured as losses, with an anti-vacuity guard so the equality cannot degenerate to `0 == 0 * n`, and seat ids read positionally so a rate belongs to the seat whose movement is measured. F-D - `published_point_names` synthesised `obj<id>` when a point's source was absent from `state.objects`. Every caller compares that string to the SUE/REED/TORCH constants, so an unresolvable source read as "not that card" and silently satisfied m1's negative owner-firewall assertion. Now a panic, matching the treatment the adjacent `other =>` arm already gave the same class of failure. The new guard is proven able to fire: `published_point_names_panics_when_a_points_source_is_absent` deletes the first published point's source and requires the panic, and reports `should panic ... FAILED` when the synthetic fallback is restored. Gates at this tip: lib 18501 passed / 0 failed / 6 ignored; integration 4514 passed / 0 failed / 2 ignored (4513 + the new row); clippy --workspace --all-targets -D warnings exit 0. The CR 603.5 prompt census and `a1_the_users_accept_committed_nothing_board_now_commits_on_every_axis` are both green. Assisted-by: ClaudeCode:claude-opus-5 * fix(engine): synchronize the forced-window state before recording the loop sample `apply_action`'s answer-beat sampler called `record_loop_detect_sample` BEFORE installing the pipeline's returned `wf`, while the settle sampler in `pass_priority_once_with_pipeline` records AFTER its `sync_waiting_for`. A frame minted at the answer site therefore snapshotted the PRE-pipeline `waiting_for`/`priority_player` pair and a settle frame the synced one. That is a detection hazard, not cosmetics: `impl PartialEq for GameState` compares both fields and `normalize_for_loop` neutralizes neither, so a heterogeneous ring breaks `ring_delta_signature`'s turn-position conjunct. Route `wf` through `game::public_state::sync_waiting_for` — the canonical synchronizer, which also recomputes `priority_player` — before the record, and drop the raw assignment below it. Blast radius is the ring only: `apply_action_boundary` already re-syncs the returned `wf` before the result leaves the engine, so the settled state is unchanged. The edit is line-neutral so the CR 603.5 prompt census keeps its line-exact `engine.rs:11549` pin (verified byte-identical by sha256, still inside `begin_pending_trigger_target_selection`). Mechanism verified at source: `is_forced_cascade_window` is a `matches!` over 13 non-`Priority` variants with a fail-closed fall-through, and the sampler's gate reads the returned `wf` while the snapshot preserved `state.waiting_for`. Evidence — instrumented probe on the pre-fix tree, `--test-threads=1`, full lib + integration; one unit = one emitted probe line = one `record_loop_detect_sample` invocation at that site. Settle site: 996 samples, 0 that the sync changed on either field. Answer site: 285 samples, 0 stale on either field. An always-true comparison of the same shape emitted on the same line is true on 996/996 and 285/285, so the zeros are a verdict rather than a dead instrument. The defect is consequently structural and latent, and this replaces a coincidence with a guarantee. New production-fixture row on the tracked `dina_conqueror_4p` dump, driven through production `apply()`: the newest answer-beat frame is `Priority{active_player}`, its `priority_player` is that seat, and the published `LoopCertificate` is exact under an exhaustive destructure. Revert-probes, measured: clobbering `priority_player` after the sync fails arm 2 (`PlayerId(3)` vs `PlayerId(0)`); clobbering the window fails arm 1 (`GameOver` vs `Priority`), with arm 2 passing first, so the arms are separately live. A pure revert of the reorder PASSES, which is the honest statement that no current fixture reaches the divergence. Gate at this tree: fmt 0, clippy --workspace --all-targets -D warnings 0, lib 18501 passed / 0 failed / 6 ignored, integration 4515 passed / 0 failed / 2 ignored (4514 -> 4515 is exactly the one new row). Assisted-by: ClaudeCode:claude-opus-5
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Removed Gittensor contributor impact section from README.
Summary
Files changed
Track
<Developer | Non-developer>
Developer
LLM
Model: <actual Frontier model identifier | not-applicable (no LLM)>
Tier: <Frontier | not-applicable (no LLM)>
Thinking: <high | max | not-applicable (no LLM)>
Human
Implementation method (required)
Method: /engine-implementer
Note
Any change to
crates/engine/game logic — parser, effects, resolver,targeting, rules behavior — is expected to go through
/engine-implementer.The "not used" box is for changes that genuinely fall outside that scope.
By Hand
CR references
Verification
Required checks ran clean, or the exact CI-owned alternative is stated below.
Gate A output below is for the current committed head.
Final review-impl below is clean for the current committed head.
Both anchors cite existing analogous code at the same seam.
<exact command or CI check>—Gate A
Gate A PASS head=<40-hex-sha> base=<40-hex-sha>
Anchored on
Final review-impl
Final review-impl PASS head=<40-hex-sha>
Claimed parse impact
None.
Scope Expansion
None.
Validation Failures
None.
CI Failures
None.
Summary by CodeRabbit