@elite-dangerous-almanac/core 0.2.11 → 0.2.13

package/PROVENANCE/astro/SOURCES.md

@@ -93,3 +93,21 @@ e3-26` sits ≈6800 ly beyond every Bleia sphere, and `Praea Aec AA-A b1-1` sits
   approximate (≈49.35 ly grid resolution); coordinates are quantised to 1/64 ly.
 - **Grid mapping:** regions sit on a `4096 / 83` ly (≈49.3494 ly) grid over the galactic
   plane, origin corner at `(x0, y0, z0) = (-49985, -40985, -24105)` ly.
+- **Manual corrections:** one. Region 31 is stored as `The Formidine Rift`. The upstream
+  transcription drops the article, and the game's own codex English carries it
+  (§`data/i18n/SOURCES.md`, acquired 2026-09-10 UTC). The game is taken as authoritative
+  for a region name, because `RegionMap.png` reads the codex names rather than naming the
+  regions itself. The Veils, The Conduit, The Abyss and The Void keep their article
+  upstream, so this is a transcription slip and not an upstream naming choice. Every
+  other region name matches the game's English exactly.
+  - **A name lookup answers the game's spelling and not the transcription's.** Resolving
+    a region by the name `Formidine Rift` misses, where it hit before the correction.
+    That spelling is what the upstream catalogues carry, and it is also the game's own
+    Spanish, so a caller holding either has to pass `The Formidine Rift`. A region id is
+    unaffected, which is why `data/i18n/codex-region-names.jsonc` is keyed by id.
+- **The game's own region raster is not a second source for the geometry.** The codex
+  localisation table acquired for `data/i18n/codex-region-names.jsonc` also carries a
+  region raster and per-region border polygons. The raster reproduces
+  `galactic-region-cells.jsonc` cell for cell, so it confirms the upstream derivation
+  and adds nothing to it. The borders are that raster's outline on cell edges, which the
+  cells already state; they are not stored.

package/PROVENANCE/commodities/SOURCES.md

@@ -46,7 +46,8 @@ readings are appended, in symbol order, after `curatedcommodity`**: `Bastnasite`
 - **The category is separately verified in the running game** (2026-09-03 UTC; no
   immutable revision), exactly as `curatedcommodity`'s is. The registry names a unit and
   its display name and does not say which market group it belongs to. Every one of these is
-  `Minerals` except `Helium` and `Helium3`, which are `Chemicals`.
+  `Minerals` except `Helium` and `Helium3`, which are `Chemicals`, and `Iridium`, which is
+  `Metals`.
 - **They are stored as standard, not rare.** The registry's English description marks a
   rare good with the phrase "This rare good". No appended unit carries the marker, no
   appended unit appears in FDevIDs' `rare_commodity.csv`, and every unit the marker does

package/PROVENANCE/i18n/SOURCES.md

@@ -109,7 +109,8 @@ tag follows the rule above, so `pt-PT` resolves to Brazilian Portuguese.
 
 ## `blueprint-names.jsonc`
 
-- **Acquired:** EDSY 2026-08-14 UTC; the in-game modification names 2026-08-23 UTC.
+- **Acquired:** EDSY 2026-08-14 UTC; in-game modification names 2026-08-23 and
+  2026-09-13 UTC.
 - **EDSY revision:** commit `e446fbe6e4597dea7ab0bd3105b9a36642388040`;
   database version `424009901`, last-modified marker `20260810`.
 - **In-game localisation revision:** none published; the game ships no immutable
@@ -139,6 +140,10 @@ tag follows the rule above, so `pt-PT` resolves to Brazilian Portuguese.
   EDSY carries with the same trailing space) and German `Railgun_LongShot`. The
   Portuguese `GuardianModule_Sturdy` and `GuardianWeapon_Sturdy` values carry a literal
   `<br>` line break for the in-game layout, which is stored as a single space.
+- **These Mercenary blueprint names come from direct in-game observation:**
+  `BeamLaser_Overloaded`, `BurstLaser_Regenerative`, `Cannon_ForceImpact` and
+  `SeekerMissileRackLarge_ExposingMissiles` carry all six observed locales. English uses
+  the catalogue's short-name style. The other locales keep the observed strings.
 
 ## `experimental-effect-names.jsonc`
 
@@ -289,7 +294,8 @@ tag follows the rule above, so `pt-PT` resolves to Brazilian Portuguese.
 
 ## `pre-engineered-variant-names.jsonc`
 
-- **Acquired:** 2026-08-18 UTC; the Merc-shop names 2026-08-22 UTC.
+- **Acquired:** 2026-08-18 UTC; Merc-shop names 2026-08-22, 2026-08-30 and
+  2026-09-13 UTC.
 - **Derivation:** every compound identity and English name comes from
   `data/ships/pre-engineered.jsonc`. An identity combines the base module symbol,
   blueprint, optional experimental effect and acquisition route. When a variant name
@@ -533,6 +539,64 @@ tag follows the rule above, so `pt-PT` resolves to Brazilian Portuguese.
   `"Posavasos Buckyball "` with a trailing space, which is layout and not part of the
   name; it is stored trimmed. Every other value is verbatim.
 
+## `codex-region-names.jsonc`
+
+- **Acquired:** 2026-09-10 UTC.
+- **In-game localisation revision:** none published; the game ships no immutable
+  identifier for its localisation tables. The acquired table is the evidence, and its
+  SHA-256 is
+  `b280c66219b2fc6d6e92120f013247fdd2404a8a7614e59c0d79a23f300ae51e`.
+- **Derivation:** every region id and canonical English name comes from
+  `data/astro/galactic-regions.jsonc`, which stays authoritative for the id set. Each id
+  joins to the in-game codex localisation identity `$Codex_RegionName_<id>;`, which
+  carries one name per locale. The join is exact and total: every region resolves, and
+  the acquired table names no region the astro catalogue does not carry.
+- **The catalogue is keyed by the region id, not by the English name.** The id is the
+  region's stable identity and the name is the value being translated, so a corrected
+  English name cannot orphan its translations. The correction below is the reason
+  this matters rather than a hypothetical.
+- **The game wins the one English disagreement, against this file's opening rule.** The
+  astro catalogue's region names are transcribed from EliteDangerousRegionMap's
+  `RegionMap.png`, which reads the game's own codex names rather than naming the regions
+  itself, so it is not an independent authority the way a ships or commodities catalogue
+  is. The game's English is `The Formidine Rift`; German, Portuguese and Russian repeat
+  it, Spanish drops the article and French translates the name. The transcription dropped
+  the article, and The Veils, The Conduit, The Abyss and The Void all keep theirs
+  upstream. The astro catalogue is corrected to the game's English
+  (§`data/astro/SOURCES.md`) and the two agree on every other region.
+- **Coverage:** complete. Every region carries all six locales. French translates most of
+  the regions; German, Spanish, Portuguese and Russian translate few and otherwise carry
+  the English name, which is the game's own value and not a fallback this project
+  manufactured. Izanami, Temple, Mare Somnia, Xibalba and Tenebrae are spelled alike in
+  all six, so those are proper nouns the game leaves alone.
+- **Some differences look like defects and are the source's own values.** A locale that
+  carries the English name does not always carry it byte for byte:
+  - **The possessive apostrophe is mixed.** Newton's Vault, Aquila's Halo, Lyra's Song and
+    Kepler's Crest carry `U+2019` in German, Spanish, Portuguese and Russian, against the
+    English `U+0027`. This is the position `suit-descriptions.jsonc` already records for
+    its own mixed apostrophes.
+  - **Achilles's Altar differs by the possessive as well as the glyph.** German, Spanish,
+    Portuguese and Russian carry `Achilles’ Altar` — `U+2019` and no trailing `s` —
+    against the English `Achilles's Altar`.
+  - **Russian carries `Ori-Cygnus Arm` for Orion-Cygnus Arm.** It is the game's string,
+    and nothing here expands it.
+  A fixture pins one of each, so normalising them fails a test rather than changing the
+  data quietly.
+- **The acquired table's region grid is not stored, because this repository already has
+  it.** The table carries a run-length region raster and a per-region border polygon
+  beside the names. The raster reproduces `data/astro/galactic-region-cells.jsonc`
+  cell for cell — the same region ids over the same 2048-by-2048 grid, with the same
+  projection — and the borders are that raster's own outline, traced on cell edges and
+  quantised to 1/32 light year against the cells' 1/64. Neither carries a fact the cells
+  do not, so importing either would be a second copy of one geometry. Re-deriving this
+  catalogue must take the names alone.
+- **The `$Codex_RegionName_<id>;` keys are not stored, and that is a decision rather than
+  a gap.** The key states the region id inside its own name, so a journal `CodexEntry`
+  yields the id by reading the number out of the key. A key column would restate what the
+  key already carries, and would have to be re-derived every time this catalogue is.
+  Storing the id alone is the smaller record.
+- **Manual corrections:** none. Every value is stored verbatim.
+
 ## Names this repository deliberately does not localize
 
 No catalogues are stored for the following names, either because the game does not

package/PROVENANCE/ships/SOURCES.md

@@ -18,6 +18,7 @@ Referred to throughout by source name; the pin is here, once.
 | Elite Dangerous in-game verification                                                            | game version `4.4.0.3`; direct in-game observation                                                                                                                          | 2026-08-14 UTC |
 | Elite Dangerous in-game purchase capture                                                        | no game version recorded; nine `ModuleBuyAndStore` journal entries from market `128666762`, 17:34-17:37, at a 10% and a 2.5% outfitting discount                            | 2026-08-30 UTC |
 | Elite Dangerous in-game outfitting observation                                                  | no game version recorded; direct in-game observation that outfitting offers no non-SCO size-8 frame shift drive                                                             | 2026-08-30 UTC |
+| Elite Dangerous in-game SCO outfitting observation                                              | no game version recorded; direct in-game observation that outfitting offers no SCO frame shift drive below the size of the mount being outfitted                    | 2026-09-17 UTC |
 | Elite Dangerous Large Planetary Vehicle Hangar readings                                         | **unreleased** — observation of the modules an unreleased update adds, plus outfitting and journal `ModuleBuy` readings at a 10% and 2.5% discount                          | 2026-09-02 UTC |
 
 Every `eddb.js` derivation uses the baseline snapshot unless its catalogue note names
@@ -434,17 +435,29 @@ FDevIDs, stats from coriolis-data and EDSY, joined on `symbol`.
     in the symbol and the display name.
   - **Derivation:** the symbol family is the classification, exactly as it is for `slot`
     above, and it is applied once here so that consumers read a datum instead of
-    matching `Int_Hyperdrive_Overcharge` themselves — which a pre-engineered or fitted
-    article's symbol does not always let them do. Stored as a sparse flag rather than a
-    `true`/`false` pair on every drive, following `alwaysPowered` and
-    `guardianZoneResistance`.
-  - **Nothing else is derived from it.** The two lines share every jump constant this
-    catalogue carries (`optMass`, `maxFuel`, `fuelMul`, `fuelPower`, and the
-    `fsdHeatRate`, which is a function of a drive's size alone — 10, 14, 18, 27, 37, 43
-    and 50 for sizes 2 to 8, identical on the plain and SCO lines at every size), so no
-    calculation reads the flag; the
-    overcharged supercruise behaviour the drives are named for has no published figures
-    and none are stored.
+    matching `Int_Hyperdrive_Overcharge` themselves. Every record carrying the flag has
+    `Overcharge` in its symbol today and no other record does, so the two agree; stating
+    the capability keeps that agreement from being something a consumer has to rely on.
+    Stored as a sparse flag rather than a `true`/`false` pair on every drive, following
+    `alwaysPowered` and `guardianZoneResistance`.
+  - **The two lines share every jump constant this catalogue carries** — `optMass`,
+    `maxFuel`, `fuelMul`, `fuelPower`, and the `fsdHeatRate`, which is a function of a
+    drive's size alone: 10, 14, 18, 27, 37, 43 and 50 for sizes 2 to 8, and where both
+    lines offer a size they state the same value. The overcharged supercruise behaviour
+    the drives are named for has no published figures and none are stored. The plain line
+    runs from size 2 to 7 and the SCO line from 2 to 8, so size 8 is stated on the SCO
+    line alone.
+  - **An SCO drive is sold only at the size of the mount being outfitted.** Outfitting
+    offers a class-4 SCO drive for a class-4 frame shift drive mount and not for a
+    class-5 one, where it does offer a class-4 plain drive — an SCO drive cannot be
+    underfitted.
+    - **Source:** Elite Dangerous in-game SCO outfitting observation, pinned above.
+    - **Derivation:** none; the observation is recorded as stated. No catalogue field
+      carries it — the drives are exactly the records `supercruiseOvercharge` already
+      marks, and every one of them states a `class` matching the `Size` token in its
+      symbol, so the flag and the class are together sufficient to state the rule.
+      Neither registry source carries a field stating such a restriction, so the
+      observation is the only evidence for it.
 - **`cabinCapacity` — a passenger cabin's berths.** The `passengerCabins` records
   carry it; every other record in all four catalogues omits it, and no cabin carries a
   zero. It is the module's own seat count, not the ship's.
@@ -732,10 +745,11 @@ the armour modules, blueprint grade rolls and crafting costs remain unverified t
 It also did not unambiguously settle the shield-generator resistances, shield-booster
 properties or probe radius. Those values are not changed on guesswork. For the
 anti-xeno, Guardian and special weapons whose damage observed in-game does not reduce honestly
-to one conventional scalar, `damageComponents` preserves the exact amounts. The two
-channel types not established by in-game verification remain `unclassified`. The
-projectile-limited hardpoints carry their boundary parameters observed in-game in
-`projectileRange`; those parameters are not presented as effective ranges.
+to one conventional scalar, `damageComponents` preserves the exact amounts. It read the
+Enzyme Missile Rack's two channels as amounts without settling the minor one's type; that
+type is caustic, and the note below records the correction. The projectile-limited
+hardpoints carry their boundary parameters observed in-game in `projectileRange`; those
+parameters are not presented as effective ranges.
 
 **A journal capture is a third source, and it reaches fields in-game verification does
 not.** Every engineered module in a `Loadout` states its own _unmodified_ value beside
@@ -847,7 +861,7 @@ Resource Siphon, the corrections are:
 | Beam Laser, Cannon, Fragment Cannon, Multi-Cannon, Plasma Accelerator, Rail Gun, Shock Cannon and Point Defence records | damage / thermal load                                             | `damage` and `thermalLoad` read from the module panel per symbol   |
 | Advanced Plasma Accelerator, Imperial Hammer, Shock Cannons and Mk II Plasma Shock Accelerator                          | burst interval / combined rate of fire                            | exact cycle values derived with the catalogue's documented formula |
 | mining, utility and Guardian hardpoints                                                                                 | clip, distributor draw, reload, jitter, falloff and maximum range | observed values per symbol                                         |
-| anti-xeno, Guardian and special weapons                                                                                 | scalar, distribution and exact damage components                  | one component record per weapon                                    |
+| anti-xeno, Guardian and special weapons                                                                                 | scalar, distribution and exact damage components                  | a component record wherever the damage needs more than a share     |
 | AX missiles, subsurface displacement missiles and seismic charge launchers                                              | projectile boundary parameters; misleading ordinary ranges absent | `projectileRange` stored; `maximumRange` and `falloffRange` absent |
 
 In-game verification gives the integer thruster/FSD masses, 1.1/1.2 enhanced-thruster
@@ -879,6 +893,37 @@ EDSY's 40 / 70. The catalogue stores the displayed values without further deriva
 applies the same correction to their exact thermal and anti-xeno components. The two
 panel readings have no upstream immutable revision.
 
+**The Mk II Plasma Shock Accelerator's damage type is Plasma, and it is stored as
+`absolute`.** Plasma is a type of its own, not a second name for absolute damage, and the
+stored share is not a claim that Frontier calls the channel absolute. What the two types
+share is the only property a damage calculation reads from either: nothing resists them.
+No shield generator, armour or hull reinforcement carries a Plasma resistance any more
+than it carries an absolute one, so the whole of this weapon's output lands whatever the
+target has fitted, and a share stored as `absolute` computes its effect exactly. The same
+reading already stores the Operations Plasma conversion's Plasma share as `absolute`,
+under "Engineering (blueprints and experimental effects)" below. What the storage costs is
+the distinction itself, which is why it is written down here: should Frontier ever give a
+defensive module a Plasma resistance, the two types stop agreeing, and this weapon and
+that blueprint are the records to revisit.
+
+Its `damageComponents` record goes with the `unclassified` spelling it replaces.
+`damageComponents` preserves amounts a fractional split cannot state honestly — an
+anti-xeno overlay, or a channel whose type is not established — and one conventional type
+at the full scalar is neither.
+
+**The Enzyme Missile Rack's minor damage channel is Caustic.** Of the 5 damage its round
+carries, 4 are explosive and 1 is caustic. The amounts are what in-game verification
+established; the minor channel's type it did not, and the share was stored as
+`unclassified` for exactly as long as that was the whole of what was known. The type is
+caustic, and the catalogue's own vocabulary says so twice over: Frontier's symbol for the
+weapon is `Hpt_CausticMissile_Fixed_Medium`, and the enzyme it delivers is the damage the
+Caustic Sink Launcher exists to shed. This is not the Mk II's situation above. Caustic is
+a type the defensive side of the catalogue already names — `causticResistance` on the
+armour and hull reinforcement records meets it, and it is one of the four resistances a build carries —
+so the spelling decides whether a defender's caustic resistance reaches this weapon's
+minor channel at all. `unclassified` would have kept it out of that arithmetic on a point
+the game does settle.
+
 **Values that look wrong and are not.** Three records break the pattern their family
 follows and are confirmed outright by EDSY. Recorded so the "breaks its family's curve"
 heuristic does not keep rediscovering them:
@@ -1476,7 +1521,7 @@ up straight through with no disambiguation at all. Both paths are evidence that
 `special_plasma_slug` is the id the game writes. This repo follows EDSY: one
 `special_plasma_slug` at damage −10% / ammo −100%, plus the `_cooled` rail-gun variant.
 
-- **Files:** `blueprints.jsonc` (per-blueprint, per-grade stat modifiers),
+- **Files:** `blueprints.jsonc` (identity, display text and measured per-grade stat modifiers),
   `blueprint-costs.jsonc` (the matching per-grade material requirements),
   `blueprint-merc-coin-costs.jsonc` (the per-roll Merc-Coin amounts the recipes that
   charge a currency bill alongside those materials),
@@ -1585,9 +1630,30 @@ up straight through with no disambiguation at all. Both paths are evidence that
     record of the same recipe is rejected: it is a copy that can drift from the one the
     game names, no observed journal, SLEF export or corpus build carries a prefixed id
     (see above), and nothing else in this catalogue keys one recipe twice.
-
-  The registry exposes **one displayed total per grade**, not a roll-bounded range, so each
-  feature stores that total as a fixed value (`min == max`).
+  - **Direct in-game observation supplies Mercenary weapon recipes.** It supplies the
+    identities, names, grade roll bounds, materials, and Merc-Coin costs for
+    `BeamLaser_Overloaded`, `BurstLaser_Regenerative`, `Cannon_ForceImpact`, and
+    `SeekerMissileRackLarge_ExposingMissiles`. The observations were acquired
+    2026-09-13 UTC. The stored decimals remove binary floating-point noise.
+  - **Direct in-game observation also supplies selected existing recipe mechanics.** It
+    supplies the grade bounds for `MultiCannon_Rapid`, `SeekerMissileRack_Drag`, both
+    `SeekerMissileRack*_Lockdown` recipes, and the named ordinary recipes in the same
+    observation. `Sensor_Expanded` includes its power-draw leg. The stored weapon rate
+    derives from the observed burst interval. The observations were acquired
+    2026-09-13 UTC.
+  - **The large Double Screaming Fragment Cannon grade-5 result is observed directly.**
+    The observation was acquired 2026-09-14 UTC. Its rate is 7.439685 shots per second.
+    Its damage rate is 336.571350 per second. Its range is 1849.624023 metres. These values
+    give the stored `RateOfFire` and `Range` multipliers. Screening Shell supplies the only Reload Time
+    reduction for both Double Screaming recipes. The effect keeps the grade-5 reload at
+    2.5 seconds, so these recipes contain no separate Reload Time feature.
+  - **The two Lockdown recipes have different Merc-Coin costs.** The medium recipe costs
+    10, 10, 20, and 40 Merc Coin per roll at grades 2–5. The large recipe costs 10, 15,
+    25, and 45. Direct in-game observation supplies both sets.
+
+  Where only the registry supplies a recipe, it exposes **one displayed total per grade**.
+  Each such feature stores that total as a fixed value (`min == max`). Direct in-game
+  observations store the observed roll bounds.
   The three Plasma conversion recipes also expose equal and opposite damage-share totals.
   Inara labels those player-facing rows **Thermal** and **Plasma**, not with journal
   modifier labels: Thermal decreases by 3.9, 6.6, 9.4, 12.4 and 15.5 percentage points
@@ -1622,11 +1688,10 @@ up straight through with no disambiguation at all. Both paths are evidence that
   each grade by its roll count.
   - **A minority of recipes charge one.** Inara's blueprint
     index marks a charging recipe by rendering its name in the coin colour, and the marked
-    set is exactly the bespoke grade-2–5 recipes a bought Mercenary article climbs plus the
-    four Operations recipes an ordinary menu lists at grades 1–5 (`FuelScoop_Efficiency`
-    and the three `*Laser_ThermalPlasmaConversion`) — 18 marked rows of the 197 the index
-    lists, fewer than the ids they price because one published recipe can answer to more
-    than one stored id. An ordinary engineer recipe is therefore **absent rather than
+    set is the bespoke grade-2–5 recipes a bought Mercenary article climbs plus the
+    Operations recipes an ordinary menu lists at grades 1–5 (`FuelScoop_Efficiency`
+    and the `*Laser_ThermalPlasmaConversion` recipes). One published recipe can answer to
+    more than one stored id. An ordinary engineer recipe is therefore **absent rather than
     zero**, and `GuardianModule_Sturdy`
     is absent for the same reason. That index is the whole evidence for the negative half
     of the claim: it is a completeness reading of one listing, not 197 pages checked one
@@ -2110,53 +2175,42 @@ base module's name: the Mining Laser and the size-5 Frame Shift Drive.
 - **`acquisition` says where each remaining variant comes from** — `mercenary`,
   `communityGoal` or `techBroker`.
   - **`mercenary`** — the Merc-Coin shop rows. Source: the in-game outfitting and
-    blueprint registries, cross-checked against Inara's outfitting and blueprint registries
-    acquired 2026-08-07 UTC (no immutable revision exposed) and Frontier's update notes.
-    Every one is grade 1, and that is the point: the
+    blueprint panels observed by the repository owner on 2026-09-13 UTC. Every one is
+    grade 1, and that is the point: the
     purchased module already
     contains the grade-1 pre-engineering, which is exactly why these blueprints' own
     recipes start at grade 2 (see the Operations section above). The two facts are
     consistent by construction: material costs for further engineering begin at grade 2.
     - **The large Seeker Missile Rack's Lockdown** is a `mercenary` row on
-      `Hpt_BasicMissileRack_Fixed_Large` at **900 MC**, taking the shop total to 13 900 MC.
-      Four things agree, none of them a guess about a module symbol: the registry keys
-      Lockdown by _size_ and the twin `SeekerMissileRackMedium_Lockdown` binds to the medium
-      rack; the large rack is already a Merc row for `SeekerMissileRack_Drag`, so the shop
-      stocks it; both Lockdown recipes run grades 2–5, the weapon-reward range that marks a
-      module as bought pre-engineered; and it is the only grade-2–5 Operations recipe in the
-      file
-      that would otherwise have no row, every other one having one. Price and size confirmed
-      2026-08-07 UTC against an index of the Inara outfitting listing, which
-      reports the MERC Lockdown Seeker Missile Rack [Fixed] at 900 MC for the 3A and 800 MC
-      for the 2B. This is an index reading rather than a pinned page capture. Both halves check
-      against rows already here — the large rack is 3A and its other Merc row is 900 MC, the
-      medium is 2B and its Lockdown row is 800 MC — and that corroboration is what carries
-      the weight.
+      `Hpt_BasicMissileRack_Fixed_Large` at **900 MC**. Direct observation supplies its
+      size, price and fixed transformation.
+    - **These shop articles come from direct in-game observation.** The observations were
+      acquired 2026-09-13 UTC. The observed panels supply each Mercenary row's
+      grade-1 fixed transformation. The burst laser's stated damage includes Regeneration
+      Sequence. Its fixed Damage change is therefore +4%, which composes with the effect's
+      −10% to give the observed −6.4%. Force Shell supplies the cannon's −16.7% Shot Speed
+      change. Feedback Cascade supplies the rail gun's Damage and Thermal Load reductions.
+      Screening Shell supplies both fragment cannons' Reload Time reduction. Incendiary
+      Rounds supplies part of the mining laser's Thermal Load increase. FSD Interrupt
+      supplies part of both Lockdown racks' Damage and Rate of Fire reductions. The
+      cannon's fixed damage split is equal parts Kinetic and Explosive. Both cargo racks
+      carry the exact multiplier implied by their observed capacities.
+      Mercenary hardpoints keep the experimental state supplied by the shop. An engineer
+      cannot add, remove or replace their effect. Direct observation acquired 2026-09-14 UTC
+      supplies this rule.
+    - **The large Double Screaming Fragment Cannon uses its exact observed firing rate.**
+      Its grade-1 rate is 2.166787 shots per second. The fixed transformation stores the
+      multiplier that reproduces this rate from the stock firing cycle.
     - **Some Merc rows carry a default experimental effect** applied beside the grade-1
       blueprint, recorded as `experimentalEffectSymbol`: Screening Shell on both Double
       Screaming Fragment Cannons, Incendiary Rounds on the Long Range Mining Laser,
       Phasing Sequence on the Rapid Phase Multi-Cannon, Feedback Cascade on the Enduring
-      Feedback Rail Gun, Drag Munitions on both Drag Seeker Missile Racks, Thermal Cascade
-      on the Lightweight Thermal Seeker Missile Rack, and FSD Interrupt on both Lockdown
-      Seeker Missile Racks. Source: repository-owner in-game observation, recorded
-      2026-08-29 UTC; no registry publishes them. These rows still carry no `modifiers`:
-      the effect is recorded, the unpublished grade-1 blueprint transformation is not.
-      - **Two independent checks each corroborate all but one, and between them cover
-        every row.** The first: the effect is one the stock module's own experimental menu
-        offers, so the shop is baking in an effect the module can carry
-        (`engineering-options.jsonc`). That covers every row but the Mining Laser, whose
-        base module offers no experimental effect at all. The second: the same base module
-        already carries the same effect on a catalogued community-goal or tech-broker
-        variant. That covers every row but the large Drag Seeker Missile Rack, whose
-        corroboration is its medium twin rather than a variant of its own symbol.
-      - **The mining laser is the weakest of them.** Incendiary Rounds is outside
-        `Hpt_MiningLaser_Fixed_Small`'s experimental menu — it is the only row a shop menu
-        could not have offered — so only the twin check speaks for it, and a twin is
-        consistency more than evidence. It is recorded because it was observed. The
-        blueprint names of the seeker racks and the rail gun do echo their effects
-        (`SeekerMissileRack*_Lockdown`, `_LightWeightThermal`, `_Drag`, "Enduring
-        Feedback"), but a name is weaker evidence than either check above, and no row
-        rests on one.
+      Feedback Rail Gun, Drag Munitions on the Drag Seeker Missile Rack and Exposing
+      Missiles, Thermal Cascade on the Lightweight Thermal Seeker Missile Rack, FSD
+      Interrupt on both Lockdown Seeker Missile Racks, Regeneration Sequence on the
+      Regenerative Burst Laser, and Force Shell on the Force Impact Cannon. Source:
+      repository-owner in-game observation. Every row carries
+      its observed grade-1 transformation in `modifiers`.
   - **`communityGoal`** — modules awarded for taking part in a community goal. Source:
     EDSY's stored-module presets, which record each reward as an encoded module state; the
     blueprint, grade and experimental effect were
@@ -2201,16 +2255,14 @@ base module's name: the Mining Laser and the size-5 Frame Shift Drive.
   Merc Coin is a separate currency with no credit equivalent, which is why it is its own
   field rather than the `cost` modules carry. Tech-broker unlocks have no equivalent
   number: they are paid in materials and commodities, so nothing is stored for them.
-- **`modifiers` is the hand-set stat block a reward variant arrives with** — what makes
+- **`modifiers` is the hand-set stat block a fixed variant arrives with** — what makes
   these records fittable rather than merely catalogued. Same vocabulary as a blueprint
   feature: a journal Modifier `label`, a `method` (`multiplicative` / `additive` /
   `overwrite`) and a `value`. Decoded from the same EDSY preset state as the blueprint
   and grade, then translated into the Almanac's own vocabulary — EDSY's attribute names
   map to journal Modifier Labels through its own table, and resistances, which EDSY
   stores in a different form from this repo, are converted using the module's base
-  resistance. Every row carries one except the `mercenary` rows, because no registry
-  publishes the grade-1 pre-engineering they arrive with and a guess is worse than an
-  omission.
+  resistance. Each Mercenary row carries its observed grade-1 transformation.
   - **Values are the authored decimals, recovered rather than rounded.** The presets
     encode modifiers in EDSY's custom 20-bit float (1 sign, 5 exponent, 14 mantissa),
     which carries about fifteen significant bits — so decoding a change the game states

package/README.md

@@ -279,8 +279,8 @@ that same id.
 
 The [repository README](https://github.com/DarkSession/Elite-Dangerous-Almanac#readme)
 contains the project guide. The generated
-[GitHub Wiki](https://github.com/DarkSession/Elite-Dangerous-Almanac/wiki) contains the
-complete API reference.
+[TypeScript wiki](https://github.com/DarkSession/Elite-Dangerous-Almanac/wiki/TypeScript)
+contains the guides and the complete API reference.
 
 ## Data and credits
 

package/THIRD_PARTY_NOTICES.md

@@ -167,7 +167,8 @@ a verbatim copy produced at build time — edit this file, never the copy.
   Frontier's own **in-game localisation** supplies the outfitting category labels behind
   the module families and their German, Spanish, French, Brazilian Portuguese and Russian
   display text, the engineering modification names in the six stored locales, the market
-  commodity names in `data/i18n/commodity-names.jsonc`, and the personal-equipment
+  commodity names in `data/i18n/commodity-names.jsonc`, the galactic codex region names
+  in `data/i18n/codex-region-names.jsonc`, and the personal-equipment
   display text in `data/i18n/`: the suit names and descriptions, the suit tool names, the
   handheld-weapon descriptions, and the names and descriptions of the engineer-applied
   suit and weapon modifications. The game's own **commodity registry** supplies the