A power request may not depend on power supply (Cut 6/F6), and continuous
consumers brown out through a power term on their own performance stats
(Cut 7). For Radiator (PumpedHeat) and AetherDrive (Torque) those were the
same stat, making six shipped catalog records illegal and leaving six
BrownoutTests cases skipped.
Resolved per the operator's ruling: a power request is evaluated
nominally -- what the item wants at full supply, not what it is currently
managing. EquippedItem.EvaluateNominalPower (mirroring ConditionRatio's
own NominalContext) pins only PowerSupplyFactor to 1; Heat/Durability
stay live, since they are not the term a request would be circular
through. Every PowerRequest/RefreshReserve/RefreshInputCapacitor
implementation now reads a StatValidation.PowerRequestFields stat through
it, so the same stat can carry a brownout curve and be a request field
without the request depending on its own answer.
StatValidation.ValidateNoPowerSupplyOnRequest (F6's static half of the
rule, forbidding the term outright) is deleted -- nominal evaluation
removes the circularity at the root instead. Only the dynamic
modifier-chain half (StatModifier.ValidateNoPowerSupplyChain) still
refuses anything, since EvaluateNominalPower forwards ScaleModifier/
ConstantModifier unchanged (real, not nominal).
Un-skips BrownoutTests' six Radiator/AetherDrive cases and adds two new
regression tests (a direct EvaluateNominalPower probe, and a two-tick
Radiator demand check) backed by a new mutation harness. Updates the four
PowerCurveTests/AetheriaStoresTests cases that pinned the now-superseded
static refusal to instead assert acceptance. GameData/Aetheria.cc is
unchanged and still validates.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
F1 power supply multiplies the resolved value (operator ruling), so zero
supply means zero and a flat stat still responds. F2 the bus agrees with
Active in both directions. F3 an empty tier reports no demand instead of
full supply, and sub-epsilon demand is rationed and subtracted. F4/F5 the
shield restores while inactive and CanTakeHit no longer mutates. F6/F7 the
validator names every stat a request reads and the tools validate before
writing. F8 re-anchors two dead mutation harnesses.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CultRecordRefs.Upsert is the one function every catalog write is supposed to
go through, but tools/AetherDb/Program.cs's Dangling, ShieldMigrate and
BrownoutMigrate commands each repair an existing record in place and must
preserve its key -- Upsert's own cache.UpsertAsync(document) cannot take a
caller-supplied key, so all three wrote raw and unvalidated through
`db.Cache.Commit(batch => batch.Upsert(document.GetType(), document, key))`.
`brownout-migrate apply` is how the shipped catalog's PowerSupply terms were
actually authored, unvalidated, the whole time.
Extracted Upsert's validation body into CultRecordRefs.Validate(object), and
call it directly from all three tool commands immediately before their own
identity-preserving commit -- the same rules, invoked where Upsert itself
cannot reach. The comment above StatValidation naming the write-bypass holes
(landed with F6) now names all four instead of two: CultCache Studio's
generic editor (still open -- not this repository's to patch) plus the three
tool commands above (closed).
Pinned in tests/Aetheria.Shared.Tests/AetheriaStoresTests.cs:
ValidateRefusesAnEquippableItemWithAZeroSpanHeatRangeTheSameWayUpsertWould and
ValidateRefusesAPowerRequestCarryingAPowerSupplyTermTheSameWayUpsertWould pin
that the extracted method actually refuses what Upsert would (fail under a
reverted Validate that is a no-op); ValidateIsANoOpForADocumentTypeItDoesNotGovern
pins that a document type it has no opinion about doesn't crash it.
Verified tools/AetherDb/AetherDb.csproj still builds clean against the pinned
CultLib worktree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
StatValidation.PowerRequestFields registered only each consumer's own
top-level request field (Thruster.EnergyUsage, Shield.Capacity, and so on),
on the premise that PowerRequest reads exactly one PerformanceStat. That was
false for five of the eight consumers: Radiator.PowerRequest also reads
PumpedHeat and WasteHeat (its own early-out gate), AetherDrive.PowerRequest
also reads Torque, LambdaMultiplier, MaximumRpm and PassiveCoupling (its
whole spin-up arithmetic), Shield.PowerRequest (via RefreshReserve) also
reads RefillDuration/RestoreDuration, InstantWeapon.PowerRequest (via
RefreshInputCapacitor) also reads Cooldown/Count, and Sensor.PowerRequest
also reads PingCooldown. Any of those could carry a PowerSupply term and sail
straight past ValidateNoPowerSupplyOnRequest, corrupting the very request it
feeds -- exactly Soul's reproduced "OK Disperser" oscillation
(SOUL_RadiatorRequestDependsOnItsOwnGrantAndOscillates).
Audited directly against each PowerRequest method's own body (and the
RefreshReserve/RefreshInputCapacitor helpers it calls into), not guessed from
the behaviour's public surface.
This correctly refuses the real catalog now: `GameData/Aetheria.cc` carries
exactly six violations --
cold like my heart RadiatorData.PumpedHeat
Arctica RadiatorData.PumpedHeat
Skiron RadiatorData.PumpedHeat
OK Disperser RadiatorData.PumpedHeat
Iapyx RadiatorData.PumpedHeat
Traction AetherDriveData.Torque
-- re-authoring them (moving the PowerSupply term off the now-covered field,
or redesigning Radiator/AetherDrive's own PowerRequest to read a
nominal/undegraded value instead) is catalog and design work for Self/roles
authoring, not done here.
BrownoutTests.cs's own Radiator/AetherDrive brownout fixtures hit the same
wall -- they authored a PowerSupply term on PumpedHeat/Torque to test Cut 7's
"curve on the performance stat," which is now correctly refused since both
behaviours' PowerRequest reads that same stat. Neither behaviour has an
untouched field left to curve, so there is currently no valid catalog shape
that gives them a working brownout curve without also feeding it back into
their own request -- a real, scoped conflict between Cut 6 and Cut 7 for
these two consumers. The six affected tests are marked Skip with a header
comment explaining the conflict rather than silently reworked or deleted;
Thruster and ConstantWeapon are unaffected (their own PowerRequest never
reads the separate field their tests curve).
Pinned in tests/Aetheria.Shared.Tests/PowerCurveTests.cs:
UpsertRefusesARadiatorWhosePumpedHeatCarriesAPowerSupplyTerm and
UpsertRefusesAShieldWhoseRefillDurationCarriesAPowerSupplyTerm -- both fail
under the reverted (top-level-field-only) registry.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
F4: a hit that breaks the shield usually also cooks it (TakeHit's own
AddHeat), which can knock the item thermally offline in the same tick. The
reserve's recharge and its Broken-clearing check lived inside Execute, which
Entity.Update only runs while Item.Active is true -- so a shield broken by a
hit that also shuts it down could never come back, no matter how long
RestoreDuration allows for. That logic now lives in Shield.Update
(IAlwaysUpdatedBehavior), which Entity.Update calls every tick unconditionally
(Cooldown.cs already relies on the same interface for the same reason).
F5: CanTakeHit broke the shield and drained the reserve as a side effect of
the query itself, on the premise that every caller queries it exactly once
per hit. That premise was false: RaycastAll/SphereCastAll/OverlapSphere hand
every caller under Assets/Scripts/Gameplay/Weapons both the shield collider
and the hull collider for one shot, so the same shield's CanTakeHit was
queried twice per hit. CanTakeHit is now a pure read (Broken + the reserve's
own CanSpend); the mutation moved to a new Shield.Break(), idempotent, called
by each weapon file exactly where it already decided to route a hit past the
shield instead of absorbing it.
Pinned in tests/Aetheria.Shared.Tests/ShieldReserveTests.cs:
RestorationProceedsWhileTheItemIsInactive (F4),
CanTakeHitNeverMutatesRegardlessOfHowManyTimesItIsCalled and
BreakIsIdempotentAcrossRepeatedCalls (F5). Updated every existing test that
relied on CanTakeHit's old mutating side effect to call Break() explicitly,
matching the new caller pattern.
Cannot compile-verify Assets/Scripts/Gameplay/Weapons/*.cs here (UnityEngine,
Unity batchmode unavailable in this environment) -- reviewed by hand for
brace/control-flow correctness; Self or a Unity batchmode pass should confirm.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AllocateTiers treated any tier whose summed demand was at or below 1e-4 as
"fully met" (ratio 1) without ever subtracting it from `remaining`. Two bugs:
a tier with no consumers equipped in it at all read as 1f, the exact "fully
supplied" signal a UI is meant to trust, even on a fully blacked-out ship
(measured: Critical 0 demand reads "fine" right next to a genuinely starved
High); and a tier with a real but tiny demand (down to 5e-5) was granted out
of nothing and never charged against the ship's actual generation, letting a
lower tier get overfed by the sliver the higher one was never billed for.
AllocateTiers now tracks which tiers actually have a consumer separately from
their summed demand. A tier with no consumer reports the new PowerBus.NoDemand
sentinel (NaN), never 1f. A tier with a consumer whose own request truly is
zero this tick is trivially satisfied (ratio 1, nothing to be short of). Any
other demand, however small, goes through the same grant/remaining arithmetic
as every other tier.
Pinned in tests/Aetheria.Shared.Tests/PowerTierTests.cs:
SubEpsilonDemandGetsNoGrantAtTotalBlackout,
HigherTierSubEpsilonDemandIsStillSubtractedFromRemaining, and
EmptyTierAtBlackoutReportsNoDemandNotFullySupplied -- all fail under the
reverted (<=1e-4 free-pass) mutation. Updated
ATierWithNoDemandPassesItsShareDown's own empty-tier assertion, which had
pinned the bug itself ("empty tiers read as fully met").
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PowerBus.Step billed every equipped IPowerConsumer's request unconditionally
and admitted a reactor on Item.Online alone, but Entity.Update only ever runs
a behaviour's Execute when the item is Active (Enabled && Online). A consumer
the player switched off never executes and never spends anything, yet was
still billed, starving live consumers and draining capacitors for nobody. A
reactor switched off stayed Online and kept generating even though
Reactor.Execute (which produces the heat receipt) never ran for it: free,
heat-free power.
Both directions now gate on the same predicate the rest of Entity uses:
item.Active.Value.
Pinned in tests/Aetheria.Shared.Tests/PowerBusTests.cs:
DisabledConsumerContributesNoDemand and DisabledReactorGeneratesNoPower --
both fail under the reverted (Online-only / unconditional) mutation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
32 of 51 designs declare roles, 183 stats point at one, 28 of 37 products
author matching role quality. Adds the validation that refuses a stat
naming a role its design lacks, and roles-migrate alongside the other
catalog tools. Product means are placeholders pending operator review.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PerformanceStat.Evaluate folded PowerSupply into the same Min/Max lerp factor
as Heat/Durability/Quality, so zero supply bottomed out at Min instead of 0
(measured: a radiator at zero power still pumped 19-25% of full; three of Cut
7's eight authored terms had Min == Max and were completely inert, since
lerp(x, x, anything) == x).
PowerSupply terms are now accumulated into their own multiplier and applied to
the fully-interpolated, fully-modified value instead of to the interpolation
factor. The term still lives in PerformanceStat.Terms -- it is still authored
per stat and still censused/validated the same way -- it is just no longer
blended into `factor`. Corrected the comments that stated the old premise
(Radiator.cs, Entity.cs, ItemData.cs's IStatContext.PowerSupplyFactor doc).
Pinned in tests/Aetheria.Shared.Tests/PowerCurveTests.cs:
APowerSupplyTermedStatWithNonzeroMinResolvesToExactlyZeroAtZeroSupply and
AMinEqualsMaxStatStillRespondsToItsPowerSupplyTerm -- both fail under the
reverted (lerp-based) mutation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
StatValidation.ValidateRoleUsage walks every PerformanceStat field on every
behaviour and refuses a StatSource.Quality term whose Role is not in the
design's own declared Roles -- wired into AetheriaStores.Open and
CultRecordRefs.Upsert alongside the existing heat/modifier/power-supply
checks. Lot.QualityForRole already falls back to workmanship for a role an
old lot never rolled (forward-compat for a role added after minting); this
is the other direction: a term naming a role the design never declared at
all is an authoring mistake, not a lot predating the role, and must fail
loudly.
RoleAuthoringTests.cs pins three rules with both a positive and negative
control: Upsert refuses an absent-role term but accepts a declared one, and
two products of one design with different ProductRole means mint lots that
resolve a role-termed stat to different, deterministic values.
tests/mutation_tests_stats_power_cut8.py (this repo's own numbering follows
cut7.py's brownout work) mutates ValidateRoleUsage in both directions
(never-refuse, always-refuse) and QualityForRole's fallback, plus
ItemManager.CreateLot's mean read -- all six behave as declared.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ConditionRatioTests.cs (8 Facts): a perfect item reads 1; the ratio falls
with durability, temperature-off-plateau, and a partial power grant, each
in isolation; it is 0 when the item produces nothing (both the ordinary
durability=0 case and the degenerate Max=0 nominal, which relies on
CultMath's NaN-favoring min/max rather than a manual guard); thrust force
for a given input is bit-identical to BrownoutTests' own pinned values,
proving Execute()'s physics is untouched by Condition being read every
tick. mutation_tests_condition_ratio_cut8.py: one mutation per rule,
mirroring cut7's harness; all 7 confirmed red (2 control/guard mutations
revised after the first pass showed them un-killable -- see the harness's
own comments).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Pins, for each of the five continuous consumers: a partial grant produces a
reduced-not-zero-not-full effect, a full grant is unchanged from today, a
zero grant produces nothing, and (Thruster, ConstantWeapon) the degradation
follows the authored exponent rather than being linear by accident.
EnergyDraw is pinned separately as the one consumer with no performance
stat of its own -- its Execute return value is the whole effect. A regression
Fact pins that InputCapacitor's all-or-nothing rule for instant items
(Cut 4) is untouched.
Each rule has a matching mutation in tests/mutation_tests_stats_power_cut7.py
(modeled on mutation_tests_stats_power_cut6.py's own shape); all eight
mutations, including the no-op control, behave as declared.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seven tests: a PowerSupply-termed stat degrades by its own authored exponent when the
grant drops and reads unchanged at full grant (the second read is deliberately taken after
a real cached value exists, so the missing-invalidate mutation is actually reachable rather
than hidden behind a fixture that only ever reads once); a stat with no PowerSupply term
never asks the context for one, cache or no cache; a power-termed stat recomputes at most
once per tick, not once per read; a thruster-style EnergyUsage field carrying a PowerSupply
term directly is refused at AetheriaStores.Open and at Upsert, naming the item and the
field; and a modifier whose magnitude carries a PowerSupply term is refused at equip when
its target is a known power-request stat, naming both items.
123 tests total (116 baseline + 7). tests/mutation_tests_stats_power_cut6.py: 10 mutations
(1 no-op control, 9 rule-killing), all behave as declared.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Six tests against the "rules worth pinning" list: critical fed in full while
a lower tier starves; two consumers in one tier rationed proportionally to
their own request, not split evenly; an empty tier passes its share down
instead of swallowing it; reactor throttling moves the line between what
starves and what doesn't; a starved tier cannot leak into a lower one; and a
tier change on an equipped item takes effect on the very next tick with no
unequip/re-equip round trip.
103 -> 109 tests. Each rule has a matching mutation in
tests/mutation_tests_stats_power_cut5.py.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ShieldReserveTests.cs covers what Cut 4's InputCapacitorTests.cs cannot: a hit within
the reserve is absorbed and spends charge; a hit beyond it breaks the shield; the
breaking hit is not partially absorbed; a broken shield absorbs nothing (gated on
Broken itself, not merely on the reserve reading empty); a break empties the reserve
regardless of pre-hit charge; a broken shield restores on RestoreDuration and not
RefillDuration; a partial bus grant stretches the refill proportionally.
mutation_tests_shield_reserve.py mutates each rule's own line and confirms the named
test goes red for exactly that reason, plus a no-op control. All 8 (7 rules + control)
verified against the pinned CultLib worktree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator ruling, 2026-09-19, supersedes Cut 4's derived reserve (EnergyUsage refilling
every second, flagged as a guess). ShieldData now authors the reserve size and two
recharge speeds directly; EnergyUsage stays the per-damage-point cost multiplier.
A hit the reserve cannot fully cover now breaks the shield instead of a silent,
charge-preserving refusal. Two follow-up rulings settle the fork the first left open:
the breaking hit passes through in full (no partial absorption -- TakeHit never runs
for it), and the reserve empties to zero on break so RestoreDuration means the same
thing every time regardless of how full the shield was.
InputCapacitorTests' shield fixture now authors the three new fields explicitly --
without them the reserve defaults to zero capacity and breaks on every hit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deletes Entity.CanSpendCapacitorCharge/TrySpendCapacitorCharge (and the
now-dead _capacitors bookkeeping list that only fed them) -- Cut 3's
named, temporary exception for the four instant draws. InstantWeapon
(both fire sites), Sensor.Ping, and Shield.CanTakeHit/TakeHit now spend
from their own InputCapacitor, filled continuously by PowerBus like
every other IPowerConsumer instead of touching the entity's shared bus
capacitors directly.
InputCapacitor's Capacity/Rate derive from the owning item's Energy and
Cooldown, with an authored-override hook (ChargedWeapon repurposes its
previously-unused ChargeEnergy stat as that override, per the map's own
instruction, rather than adding a new field). A weapon/sensor fire
attempt only ever spends exactly Capacity, so it only ever succeeds at
full charge -- no fractional shot. Shield is the map's named exception:
its reserve is continuous, not an activation buffer, so it allows a
partial draw; its size (no Energy/Cooldown pair exists on Shield) is a
flagged judgment call, not a spec'd formula.
Adds InputCapacitorTests.cs (8 tests) and
mutation_tests_stats_power_cut4.py (7 mutations, all behave as
declared); removes the one PowerBusTests.cs test and Cut 3 mutation
case that exercised the now-deleted Entity methods.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deletes Entity.CanConsumeEnergy/TryConsumeEnergy and Reactor's own capacitor
draining/filling (the demand-mechanism halves of Reactor.cs:90-141); adds
PowerBus (one per Entity, stepped once per tick before equipment executes),
IPowerConsumer on the five continuous draw sites (EnergyDraw, Thruster,
AetherDrive, Radiator, ConstantWeapon), and EquippedItem.PowerSupply as the
bus's grant ratio. Reactor keeps only its heat/throttle arithmetic, now driven
by PowerBus.NetDraw instead of an accumulator any behaviour could add into.
The four instant draws (InstantWeapon's burst/shot, Sensor's ping, Shield's hit
taken) are out of scope for the bus this cut per the map; they spend capacitor
charge directly and atomically via the new Entity.TrySpendCapacitorCharge/
CanSpendCapacitorCharge, replacing TryConsumeEnergy's old partial-drain-then-
refuse bug for that path too. Named, temporary exception closed by Cut 4.
docs/stats-and-power-cut.md Cut 3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
StatResolverTests: UnequipReturnsTheResolversRetainedSetToBaseline and
ConsumableExpiryReturnsTheResolversRetainedSetToBaseline drive 20 equip/
evaluate/unequip and activate/evaluate/expire cycles and assert the
resolver's own entry counts return to baseline, pinning Gate 1 at the
retained-set level rather than only via one WeakReference.
ARefitTargetReattachesTheModifierAfterReactivation drives the exact refit
scenario Gate 2 fixes and asserts the replacement target ends up boosted.
tests/mutation_tests_stats_power_cut2.py: one mutation per Forget() call site
(each expected red under deletion of that call), one for Gate 2's detach line,
and the StatOwner mutant swapped for Entity to match its removal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PerformanceStat kept two Dictionary<Entity, ...> fields for attached modifiers,
grown by one key per entity that ever evaluated the stat and never trimmed
(docs/stats-and-power-cut.md §0.3). StatResolver.cs is the new sole owner of
every resolved (item, stat) value and every attached modifier, one instance
per Entity and reachable only from it. EquippedItem and ConsumableItemEffect
now read and write through it instead of through the catalog object; the two
dictionaries and their four accessors are deleted outright, not hidden.
StatModifier no longer resolves its (type name, field name) reference by
runtime reflection search on every equip: StatValidation.ResolveStatField
does it once, memoized, and StatValidation.ValidateStatModifiers checks it at
catalog load and at Upsert, naming the record instead of failing with an
opaque NullReferenceException the first time something equips it. A modifier
whose own magnitude stat is (directly or transitively, through another
modifier on the same entity) one of the stats it writes is refused at equip:
resolving it would depend on a value computed from itself one tick late.
A resolved value now caches by the generation of the sources its declared
Terms actually read, invalidated per source by EquippedItem.UpdatePerformance
(Heat, Durability) and ConsumableItemEffect.Update (ConsumableProgress), so a
stat recomputes only when a term it declared moves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
StatValidation.ValidateHeatResponse now refuses NaN in any of the four heat-response
fields, a zero-span range (Minimum == Maximum -- Tractor Beam's exact bug), and a
plateau whose low or high edge pokes past its bounds, matching the R-heat ruling and
the Performance() comment that already claimed this was enforced. The writable-path
hole is closed for every path this repo owns: CultRecordRefs.Upsert (AetheriaStores.cs),
the one function every tool, test and migration script writes catalog documents
through, validates before a write reaches disk instead of waiting for the next Open().
CultCache Studio's generic editor bypasses Upsert and still has no per-document
validation hook -- that hole is CultLib's, not this repo's, and stays named in the code
rather than silently assumed closed.
EquippableItemData's four heat fields get non-degenerate defaults (0/100/50/20, the
same shape HeatResponseTests already hand-authors) because dozens of existing test
fixtures across the suite build designs that never cared about heat and defaulted into
the same zero-span trap Tractor Beam shipped with; enforcing the zero-span refusal
without this would have required touching every one of those fixtures instead of the
root cause.
Four new mutations pin S7's survivors, each with its own dedicated test rather than a
coincidentally-sensitive existing one: out-of-bounds semantics (return 1f instead of 0f
outside bounds), the plateau-clamp validation's two sides, and a Quality term ignoring
its own exponent (StatsReadTheLot's Exponent = 1 everywhere could not tell "reads the
exponent" from "always uses 1"; the new test uses Exponent = 2). Performance()'s own
runtime plateau clamp is separately confirmed dead code -- the outer bounds guard makes
it unobservable at every input, verified by an exhaustive numeric sweep -- and is
recorded as such rather than forced into a fake kill.
80 tests (9 new), 17 mutation cases in tests/mutation_tests_stats_power_cut1.py, all
green.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PerformanceStat's four fixed fields (HeatExponentMultiplier,
DurabilityExponentMultiplier, QualityExponent, FromRole) tombstone into a
declared List<StatTerm> (source + exponent + role), walked by the one
evaluation path Cut 0 unified. A stat with no terms resolves to Max (the
same identity a stat with all-zero exponents already produced), so the
migration is exact: a zero multiplier becomes no term, not a term with
exponent 0.
R-heat (operator, docs/stats-and-power-cut.md): EquippableItemData's
HeatPerformanceCurve (a BezierCurve, plus the 100-sample scan that inferred
OptimalTemperature and its cache) is retired in favor of an authored
minimum, maximum, optimum and plateau width, with linear falloff outside
the plateau. StatValidation refuses an optimum outside its bounds or a
negative plateau width, loudly, at catalog load. The plateau's consequence
rides along for free: Wear's thermal term is pow(ThermalPerformance, ...),
and Performance() now returns exactly 1 across the plateau, so a
well-managed item takes wear only from deltaTemp there -- the
operational-lifespan lever the operator asked for.
ConsumableItemEffect's progress-through-duration substitution for "heat"
becomes its own StatSource (ConsumableProgress) rather than an unconditional
override applied regardless of what a stat declares.
Tests: LoadoutTests' four PerformanceStat-shaped fixtures rebuilt against
Terms/authored heat fields; HeatResponseTests.cs (new) pins load
validation, the plateau shape, and the three wear-lever claims (held
inside takes no thermal wear, held outside does, a fast swing across still
wears) each under its own mutation in tests/mutation_tests_stats_power_cut1.py
(new, 10 rules including a no-op control; all pass).
64 pre-Cut-1 tests still pass unmodified; 71 total with the 7 new ones.
Unity batchmode: 0 error CS. ShieldPanelCut1Verify and Cut2Verify pass;
Cut3Verify fails with an unrelated pre-existing "Kernel 'KInit' not found"
compute-shader error, reproduced against Cut 0's own landing state with no
shader/compute file in this diff -- flagged for Soul, not fixed here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three new LoadoutTests, each a check the cut map requires (docs/stats-and-
power-cut.md Cut 0):
- UnequippedAgreesWithEquippedAtFullHealthAndOptimalTemperature: the
agreement the map names as the cut's own test. Real catalog curves rarely
sample to exactly 1.0 at their reported OptimalTemperature (a probe found
12/30 heat-bearing stats disagreeing there), so this pins the design
contract with a controlled flat-topped fixture rather than live data --
heat curve semantics are Cut 1's R-heat ruling, not this cut's.
- UnequippedIgnoresHeatRegardlessOfTemperature and
ConsumableEvaluateSubstitutesProgressForHeatUnconditionally: the two named
disagreements the cut preserves rather than resolves.
tests/mutation_tests_stats_power_cut0.py mutates each context's identity
factor (the constant a context returns instead of a term it structurally
cannot have) and asserts the right test goes red; a no-op control proves the
harness itself is transparent. All four cases pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entity's constructor now takes a MessagePack round-trip copy of the settings
it is given, so no entity can alias GameplaySettings.DefaultEntitySettings.
That makes ActionGameManager.NewEntitySettings and EntitySerializer.Unpack's
null-coalescing copy redundant; both are deleted, and TradeMenu buys a ship
straight off the template (Entity's ctor copies it).
EntitiesDoNotShareDefaultEntitySettings pins the invariant: writing
ShutdownPerformance on one ship must not move the default for a sibling or
the template (settings-globals-cut.md, Cut 0).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ActionGameManager.Sensitivity was a Unity-serialized public float2, but
CultMath's float2 isn't Unity-serializable, so ARPG.unity's stored value
loaded as zero and mouse look went dead. Sensitivity is a player
preference, so it belongs in PlayerInputSettings (key 2) with the prior
default (-0.001, 0.001) as a field initializer, so a pre-existing player
store missing the key still deserializes to the working default instead
of zero. ActionGameManager now reads PlayerSettings.InputSettings.Sensitivity
directly; no cached copy on the MonoBehaviour. Adds a pinning test that
simulates an old store lacking key 2 and asserts the default, plus a
round-trip test for a non-default value.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CapabilityEventsTests.EachEventKindReachesOnlyItsOwnSubscribers publishes one
of each event kind and asserts every subscriber list holds exactly its own
event -- a subscriber to Absorb must never see a Grab/Melee/Thrust event.
Mutation entry in tests/mutation_tests.py kills a mutant that makes
PublishAbsorb also notify the Thrust stream, plus a no-op control proving the
mutation script's own read/replace/restore path is transparent for this file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
IffAndCombatTests builds a minimal headless world (CultCache catalog, a Ship
hull and a gun with InstantWeaponData, an empty Zone/GalaxyZone) and pins:
override decides outright; clearing restores the derived rule; leaving the
zone clears overrides; the derived reciprocity path can't mirror another
entity's override; grudge triggers immediately whether the mark or the
detection happens second, is detection-gated, is sticky, and never fires for
a player-controlled entity; PerceivedStanceOf is unknown until detected;
Weapon.StanceAllowsFire and InstantWeapon.Trigger refuse to fire on a neutral
target and fire on a hostile one (and with no target at all); LockWeapon
builds lock on the shooter's own stance, not the target's; and
ZoneGenerator.EligibleWandererFactions excludes the owner and nearest faction
(and is empty when neither is eligible).
Adds one mutation per rule to tests/mutation_tests.py, all KILLED against
this HEAD (control still GREEN).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Brand()'s ordering by record key was only exercised indirectly, through
a test that gives each candidate product a different maker. Add a test
with two FactionProductData for the same maker and same design, distinct
record keys, asserting Brand returns the one first in record-key order.
Add the corresponding mutant (OrderBy -> OrderByDescending at Brand's
ordering) to mutation_tests.py so a regression there gets caught.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The manufacturer does not belong to a design (operator ruling); it lives on
FactionProductData and branding is derived, never stored on the design.
- Delete ItemData.cs key 3 (Manufacturer), with a retired-key comment.
- AetherDb census now attributes a design's maker to the first product (in
record-key order) that sells it, matching ItemManager.Brand's rule; a
design no product sells shows "(none)".
- AetheriaStoresTests' catalog fixture moves its Manufacturer reference onto
a FactionProductData selling the design, and FactionIsASingletonInstance
reads it from there.
- mutation_tests.py gets a paired mutation for that fixture wiring.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator ruling (docs/item-provenance-cut.md Progress header, 2026-09-17):
delete EntityPack.PersistedBehaviors, IPersistentBehavior,
PersistentBehaviorData and MarkerPersistentBehaviorData outright rather than
keep patching around a feature with no production writer. Key(5) is retired
and left unused; other MessagePack keys are untouched.
Removes the pack/unpack code that read and wrote the field, the feature-only
test ReopenedPackKeepsPersistedBehaviors and its BarePack initializer, and the
matching "not yet reached" mutation notes in tests/mutation_tests.py.
ReopenSurvivesAGeneratedShipWithEntities is kept: it pins the reopen defect
class against a real generated ship, independent of this feature.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds tests for behavior that Cut B shipped without coverage:
- GetPriceReadsLotQuality: price varies with the lot's quality through
GameplaySettings.QualityPriceModifier.
- EvaluateDurabilityExponentReadsLotQuality: ItemManager.Evaluate's
durability exponent path reads the lot's quality independently of the
quality-for-role term.
- EquippedItemThermalExponentReadsLotQuality: EquippedItem's thermal
exponent (Entity.cs) reads the lot's quality on a real equip.
- CreateLotFillsRolesFromProductSpread: CreateLot(product) fills role
quality from the product's own per-role spread, not the design default.
- BrandReadsProducedFaction: Brand resolves the maker off a Produced
origin, not only Attributed.
- CommitTakesRootsFromEveryZone (RunSaveTests): GC roots are collected
from every committed zone, not only the first.
All six verified by mutation (GetTier/Evaluate/CreateLot/Brand paths
patched to ignore the lot or return a fixed value; RunSave.Commit's roots
truncated to zones.Take(1)) and reverted after confirming the kill.
42 of 42 tests pass on the real code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A single-tier fixture cannot fail "GetTier ignores lot quality": every
lot resolves to the only tier regardless of its own Quality. Added a
second tier (Rare, threshold .5) and a second lot whose quality (.6)
lands in it, and asserted GetTier resolves each lot to its own tier.
Also asserts that minting a second instance from an existing lot does
not re-roll the lot's quality.
Verified by mutation, then reverted: GetTier hardcoded to a fixed
quality, and CreateInstance(int) re-rolling the lot's quality, both
fail this test. 36 of 36 tests pass on the real fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The test read reloaded instances through EntitySerializer.Items, the same
enumerator RunSave.Commit uses to compute GC roots. Dropping a root from
Items would silently agree with itself: the root's lot would never be
written, and the test would never look for it.
Rewritten to hand-mint one real lot per EntityPack root (Hull, Equipment,
CargoBays, DockingBays, CargoContents, Children, DockingBayContents)
through ItemManager, so the expected lot ids are known independently of
any enumerator, then read the reloaded pack's own fields directly.
Verified: reverting Items to skip the Equipment root now fails this test
with "Lot 2 is not in the provenance ledger" (previously green). Reverted
after confirming the kill; 36 of 36 tests pass on the real fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Dictionary<int2, PersistentBehaviorData[]> has no hash-resistant comparer
under CultCache's UntrustedData security, so any run store holding an
entity threw MessagePackSerializationException on reopen, even when the
dictionary was empty. EntityPack.PersistedBehaviors (key 5, unchanged)
becomes (int2 position, PersistentBehaviorData[] data)[], matching
Equipment/CargoBays/DockingBays. Pack writes pairs; Unpack builds a local
lookup before restoring behaviors.
PersistentBehaviorData had no concrete leaf and no Union, so nothing could
ever exercise its wire format; added MarkerPersistentBehaviorData as the
one placeholder leaf so ReopenedPackKeepsPersistedBehaviors can round-trip
real data ahead of a real IPersistentBehavior implementer landing.
Tests: RunSaveTests.BarePack uses an empty pairs array.
Added ReopenedPackKeepsPersistedBehaviors (a hand-built pack with two
positions, each with one persisted behavior, round-trips through commit
and reopen) and ReopenSurvivesAGeneratedShipWithEntities (a real ship from
LoadoutGenerator against a catalog fixture, committed into a SavedZone and
reopened, pinning the defect at the layer Soul's probe found it).
MaterializedLotsSurviveSaveAndReload and CommitKeepsOnlyReachableLots go
green; 36 of 36 tests pass.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Every existing ItemManager/RunSave.Commit call site now threads a
ProvenanceLedger. Five new tests and one rewrite cover the rulings this
cut lands: a materialized ship's lots survive a real save and reload
with unchanged quality and Attributed provenance; RunSave.Commit keeps
only lots reachable from a save's packed entities, closing over
Produced.Facility/Inputs, while the live ledger keeps everything;
ProvenanceLedger's indexer and Reachable are loud on a missing lot;
matching hardpoints mint from the same lot; Evaluate/GetTier read a
lot's Quality and per-role fills; and Brand's first-in-key-order rule
is asserted directly instead of through the old Product field.
Two of these (MaterializedLotsSurviveSaveAndReload,
CommitKeepsOnlyReachableLots) currently fail: committing any EntityPack
into the run store and reopening it throws
`TypeAccessException: No hash-resistant equality comparer available
for type: CultMath.int2`, because EntityPack.PersistedBehaviors is a
Dictionary<int2, ...> and CultMessagePackSecurity registers a
collision-resistant comparer only for CultRecordRef<T>. This predates
this cut (PersistedBehaviors is untouched here) and is a CultLib gap,
not a defect in this schema; see the landing report.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Opening the process cache's catalog writable in the editor was the wrong cut.
It made catalog read-only only by convention, so a stray catalog write in play
succeeded and a later flush could land play-mutated instances in Aetheria.cc.
- The process cache opens the catalog read-only in every build again, so the
missing-global check runs for it as it did before db83cd29. The writable
empty-seed exemption from ab4ced0f stays for AetherDb and fixtures.
- Loadouts.Commit(catalogPath, loadout, replace) is the only preset writer. It
opens its own short-lived cache over the catalog, writable, commits the one
preset conditionally on its key and disposes it. No other cache or instance
is touched. The running game sees the preset only after the catalog reloads.
CultLib at a0813c6 allows this: a read-only single-file store takes no lock
and holds no handle, and the writer's commit takes the exclusive sidecar
<path>.lock and replaces the file atomically.
- Capture refuses, writing nothing, when Aetheria.cc is missing (it never
creates the catalog), when a preset of that name exists under another key
(CultCache does not reject duplicate names on write), or when the key holds a
preset and replace is not given.
- The console refuses a command with any character outside letters, digits,
spaces and hyphens instead of stripping it, so "Mk.II" can no longer become
"MkII". capturepreset refuses a second argument other than replace, so an
unquoted capturepreset My Ship refuses instead of saving "My".
- The capture log line says the session sees the preset after a reload, and
that a Studio session opened earlier overwrites captured presets on save.
- Tests: capture while the process cache holds the catalog read-only leaves it
unchanged; a missing catalog refuses and creates nothing; a same name under a
Studio-minted key refuses, with or without replace; a game-shaped read-only
open missing a global throws. The existing preset tests now commit through
the catalog path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Globals are owned by lifecycle, so the cache must never run without one,
however the catalog is opened. Before this, opening the catalog writable
skipped the check entirely. The editor now opens the catalog writable, so a
missing global went silent in play mode.
AetheriaStores.Open now skips the check only for a writable catalog that
has no records: a seed store being authored from nothing, as the test
fixtures do. A populated catalog is always checked, and so is a read-only
empty one. Nothing else relied on the old skip: the game has no catalog
globals, AetherDb opens the populated Aetheria.cc, and every writable test
reopen already holds its fixture global.
WritablePopulatedCatalogMissingGlobalIsLoud removes the global from a
populated catalog and checks that a writable reopen throws. It fails when
the old writable-skip condition is restored.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Loadouts are ship presets (variants) for spawners, not a player feature.
- Route Loadout to the catalog; the player store no longer holds it.
- Materialize takes no credits: affordability, the charge and Loadouts.Price
are deleted, since only the player menu priced loadouts. Availability,
key-order product choice, all-or-nothing failures and the weapon-group
rules stay.
- Delete the InventoryPanel Save Loadout and Restore Loadout entries and
RestoreLoadout, which also removes its docking-bay overwrite.
- The editor opens the catalog writable in the one process cache, and the
editor-only console command capturepreset "<name>" [replace] captures the
piloted ship. Loadouts.Commit keys a preset by name, refuses a same-name
replace unless asked, and commits conditionally on that key. The single-file
store then lands only that record onto the file as it is on disk. An
unconditional commit would re-serialize every live catalog instance,
including any that play has mutated.
- Tests: capture -> commit -> fresh reopen round-trip, explicit replace with
no duplicate, and a preset commit that does not persist a mutated live
Faction. The money-only tests are removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Materialize now reports a weapon group index whose slot design has no
WeaponData, and a loadout with more groups than WeaponGroupCount. The ship
always gets exactly WeaponGroupCount groups, and a shorter loadout is padded
with empty groups. Both checks run before anything is built.
Price is summed as long, so the hull add can no longer wrap to a negative
price that pays the player. A price beyond int credits is simply unaffordable.
Deleted Capture's index >= 0 filter and its test. Every production writer of
WeaponGroups items (WeaponGroupAssignment, GenerateWeaponGroups, Unpack replay
of Pack, Materialize) groups only weapons, and TryUnequip removes weapons from
groups, so nothing produces an ungrouped index any more.
The Materialize comment now says a failed fit may already have advanced
itemManager.Random.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Materialize, which already charges, now also owns affordability: when credits
are below Price it lists "cannot afford <price> credits" and builds nothing.
The restore menu's separate price < Credits check is deleted; the menu still
shows Loadouts.Price and lists Materialize's failures.
Tests: one credit short builds nothing, leaves credits unchanged and lists the
failure. A fixture gun with an InstantWeapon behavior proves TryUnequip removes
the weapon and its item from every weapon group.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The key-order test wrote its products and then reopened the store, whose
snapshot already returned them in key order, so removing the explicit OrderBy
still passed. The products are now committed into the open cache in z-then-a
order, the test asserts that enumeration order first, and Materialize must
still pick lamp-a.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entity.TryUnequip does not clear WeaponGroups, so Capture saved -1 for a
grouped item that was no longer equipped, and Materialize later threw
IndexOutOfRangeException after every other check passed. Capture now skips
group items that are not equipped. Materialize reports every weapon-group index
outside the loadout's slots as a failure before building anything, so a stale
or hand-edited record builds nothing and charges nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Materialize takes isAvailable as a Predicate<FactionProductData>; the restore
menu passes LoadoutGenerator.IsAvailable for the docked station, so generation
and loadouts still share one availability rule. Candidate products are ordered
by record key, so "first available product" no longer depends on dictionary
order. Materialize charges Price through ref credits only when it returns a
ship; RestoreLoadout no longer subtracts on its own.
Tests: a slot that resolves but does not fit builds nothing, charges nothing and
is listed; Price is the sum of design prices and is charged on success; the
first available product in key order builds a slot, a later one is used when
the first is unavailable, and none available fails the slot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the 8a follow-up. string.GetHashCode is stable on Mono but randomized
per process on .NET Core, so a headless sim that generates zones would get
different zones on every run.
- Extensions.StableHash folds a string's UTF-8 bytes through CultMath's pcg
from the FNV-1a offset basis. No new CultMath API.
- ZoneGenerator seeds from `Name.StableHash() ^ pcg3d(Position).x`.
- Zone seeds from `Name.StableHash() ?? 1337u`. CultMath's Random maps
seed 0 to its default, and the abs/Convert.ToUInt32 pair that threw on
int.MinValue is gone.
Old runs are discarded, so a different galaxy per seed costs nothing.
Tests: StableHashIsNotProcessRandomized pins "Adrasteia" to 2427892944, the
value an independent Add-Type transcription of CultMath's pcg produced. It
fails with GetHashCode substituted back in.
Builds: headless, 15 tests pass, Unity batchmode compile reports no error CS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Loadout.cs owns loadouts: the document, capture, save and materialization.
- Loadout ("aetheria.loadout", player store) holds a hull design ref, and
per slot a hull cell, a rotation and an EquippableItemData design ref,
plus weapon groups as slot indices. It names no product, manufacturer,
unit roll, cargo, faction, position or behaviour state.
- Loadouts.Capture records the hull design and one slot per equipped item
(gear, cargo bays, docking bays). Entity.Equipment also holds the hull's
own unit (MapEntity adds EquippedHull); that is Loadout.Hull, not a slot.
- Loadouts.Save is the only writer: one Commit to the player store, reusing
the existing key for the name.
- Loadouts.Materialize is the only builder of a ship from a loadout. For
the hull and each slot in order it resolves the design and takes the
first product in catalog order that LoadoutGenerator.IsAvailable (now
public) accepts, with no any-manufacturer fallback. Every failing slot is
listed; units are built only after everything resolved, and any resolve
or fit failure returns null with no ship, no charge and no write.
- Loadouts.Price is the hull design's price plus each slot design's price.
- InventoryPanel: Save Loadout asks for a name (default: the ship's name)
and saves the capture. Restore Loadout, shown when docked with saved
loadouts, lists each with its price, debits credits only after
Materialize succeeds, then docks the ship as before; a failure opens
"Loadout cannot be built here" with one line per failing slot.
Tests: new LoadoutTests (3): LoadoutRoundTripsThroughAFreshCache,
LoadoutHoldsNoRunOrGalaxyRefs, MissingDesignReports. Each fails with its
rule mutated out. The fixture hull is 3x3, not the spec's 2x2:
HullData.InteriorCells is Shape.Shrink(), so a 2x2 hull has no interior
cell a cargo bay can occupy.
Builds: headless, 14 tests pass, Unity batchmode compile reports no error CS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Owner: ActionGameManager composes the process's one cache. Its CultCache
getter attaches the catalog, GameData/run.cc and GameData/player.cc on
first access, in either scene, and nothing reopens it.
- RunSave (SavedGame.cs) replaces the SavedGame constructor:
- Capture builds the live run as plain documents and writes nothing. Zone
contents are `zone.Contents?.PackZone() ?? zone.PackedContents`, so a
zone generated earlier but not loaded this session keeps its contents
and its orbit and body records instead of being erased by the next save.
- Commit is the only writer of SavedGame and SavedZone: one Commit with
zone i at `savedzone-{i}`, SavedGame.Zones set to those refs, and every
stored SavedZone outside that set removed. Orbits and bodies staged by
zone generation land in the same single-file write.
- Clear removes every run record in one Commit.
- Run begins: New Game's first statement is RunSave.Clear. Run saves:
ActionGameManager.SaveRun at wormhole arrival and quit. Run ends: Die
clears the run, then saves settings.
- Run exists only as the run store's SavedGame global: MainMenu enables
Continue from it (and logs when the run store holds records but no
SavedGame), and StartGame reads it once to pick the new-run or resume
branch.
- PlayerSettings: the getter returns the player store's global and, on
first launch, commits GetDefaultPlayerSettings; it is the only creator.
SavePlayerSettings commits the instance.
- InputDisplayLayout reads its InputLayout from the catalog by the layout
asset's name and throws when the catalog has none.
Tests: new RunSaveTests (5): RepeatedSavesKeepRecordCountConstant,
SaveRemovesZonesNoLongerInTheRun, SaveWritesOnlyTheRunStore,
ResumeThenSaveKeepsUnloadedZoneContents, ClearRemovesEveryRunRecord. Each
fails with its rule mutated out.
Builds: headless, 11 tests pass, Unity batchmode compile reports no error CS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AetherDb gains legacy-census and a one-shot import (tools/AetherDb/Import.cs,
deleted by Cut 10). The import rewrites each legacy [tag, payload] record by
the target type's [Key] shape: slot 0 Guid becomes the record key and nil,
CultRecordRef members and DatabaseLink wrappers become D strings, the all-zero
Guid becomes nil, StatModifierData.RequireBehavior keeps the simple type name.
All 180 records land in one Commit; a second import refuses.
InputLayout moves to the catalog (Q9-1 A), with the test fixture seeding it
while the catalog is writable. GameData/*.cc is LFS, GameData/*.lock ignored.
The legacy msgpack and ansi104.json sources are removed.
Imported: SimpleCommodityData 13, CompoundCommodityData 51, GearData 25,
HullData 3, NameFile 12, Faction 12, PersonalityAttribute 3, CargoBayData 4,
DockingBayData 1, WeaponItemData 18, FactionProductData 37, InputLayout 1.
Six refs dangled already in the legacy data and are preserved as authored.
The Key(0) precondition checks only the Guid-slotted tagged types; InputLayout
is imported bare and keeps its Key(0).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cut 8b. tests/Aetheria.Shared.Tests (xunit, net10.0) builds a temp-directory
catalog through AetheriaStores.Open(catalogWritable: true) per test:
- OpenThenFlushLeavesEveryFileByteIdentical: the catalog, plus run and
player stores seeded with their globals, a SavedZone and an InputLayout.
- WeaponWrittenThroughGearHandleReloadsAsWeapon
- CatalogRefusesWrites: bytes unchanged too.
- SavedZoneNeverLandsInCatalog: no home without a run store; the snapshot
schemas show where it landed.
- FactionIsASingletonInstance: through a ref, a ref-keyed map key, and the
name index.
- MissingCatalogGlobalIsLoud: uses a test-only [CultGlobal] routed to the
catalog. The game has no catalog globals yet.
The first test found a real defect. PlayerInputSettings.InputActionMap was
keyed by (string, int), and CultLib's untrusted-data MessagePack security
has no hash-resistant comparer for a tuple, so a player store could never
be read back. It is now action name to binding index to path; its two
Unity readers change in the Unity commit.
Each test was checked to fail with the rule it pins removed; see the
report.
Builds: Aetheria.Shared, AetherDb, Aetheria.Shared.Tests (6/6 pass).
Unity does not build yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
