Royal Revenue

v1.38.2 (2026-10-17)

Full Changelog

• v1.38.2: a current fixture, and what it taught
  Last of the six ideas. Done on its own deliberately: regenerating the fixture
  invalidates every baseline at once, and then the diff cannot tell a code change
  from a data change.
  fixtures/sv13.lua and harness13.lua hold today's SavedVariables. sv11 is from
  07/10 and lacks the fields added since (spdProjected, saleFromContainer,
  entry.ver), so the tests were running against a reality that no longer exists --
  which is why the Bouquet in sv11 still counts 65.9% in t118. The older tests
  stay on sv11 on purpose: a regression baseline is only worth anything while the
  data stays put. Anything new that needs realistic data uses 13.
  t124.lua checks this series' fixes against the real data: 965 recipes, both
  share calculations agreeing on every one of them (CountsInShare), provenance
  (755 firm sale prices, 2 weak), and all 8 tabs drawing with nothing outside the
  canvas.
  What the new fixture taught: the first version of the test flagged "Assorted
  Exotic Spices at 91.9% of Cooking" and I nearly treated it as the Bouquet all
  over again. It was not -- that profession has 3 recipes with sales data, and the
  largest honestly takes 92%. Then "Bright Linen Bolt at 68.3% of Tailoring"
  showed up, also legitimate: it is the cloth bolt, it really does sell 6,093/day,
  no projection and no binding.
  Dominating is not a defect. The defect is dominating WITHOUT being a real sale
  -- a container projection or an item that cannot go to the auction house, which
  is what the Bouquet was. The test now flags only that, and ignores professions
  with fewer than 10 recipes, where a share means nothing.
  Co-Authored-By: Claude Opus 5 noreply@anthropic.com
• v1.38.1: one source for derived numbers, provenance in one place
  The two I had left out of v1.38.0 for being too large on the eve of a release.
  One source for derived numbers. Two rules were written in more than one place,
  and letting them drift was the factory behind the last three wrong numbers:
  • "does this row count in the sales share?" -- ApplyABC and BuildView held
    separate copies. That is what left the Bouquet at 41% in the column after it
    had already been excluded from the filter.
  • "profit = sale x qty - cut - cost" -- written in Scanner, twice in Invest, in
    two tooltips and in the NPC resale row. When v1.37.0 changed the input price,
    three copies were left behind.
    They are now ns.CountsInShare(r, forConc) and ns.NetProfit(unit, qty, cost,
    cut), and everyone calls them. The NPC resale row, which I had not noticed
    before, now uses the projected price too.
    Provenance. "Where did this number come from and how much can I trust it" was
    scattered across saleFromContainer, saleOpens, spdProjected, SpdIsEstimate and
    audit.prices. It is now ns.Provenance(r, field), returning the source, a level
    (firme / estimado / projetado / fraco) and a note. The audit tab gained a
    "where the numbers come from" block covering sale, tier-2 sale, sales/day and
    materials, each coloured by level -- so a sale of 720,542 visibly comes from the
    average of 3 container opens instead of looking like a firm price.
    Tests: t122 (CountsInShare over 8 cases, NetProfit including a missing price
    and the cut from config, Scanner using its own function, and a source scan that
    fails if anyone rewrites * (1 - cut) outside it, with the exceptions marked in
    the code), t123 (provenance for sale/velocity/cost at every level and the new
    block, nothing outside the canvas). t115 changes on purpose: the audit tab went
    from 66 to 75 texts.
    The refactor is behaviour-neutral: outside the new tests and t115 the suite
    showed no differences at all.
    Co-Authored-By: Claude Opus 5 noreply@anthropic.com