Commit Graph
295 Commits
Author SHA1 Message Date
SenrokaiandClaude Opus 5.5 89c2568018 Describe the star at a system's centre as it is drawn now, not by the innermost-orbit rule and its halo
The README still said the star was sized against its innermost orbit and made visible by a halo,
two things 7213f98 and 2242fe0 removed. It now says what the view draws: the star at its own
radius on the orbits' scale, the archive's for a host and derived from luminosity and temperature
otherwise, marked "from colour and brightness" on the card; a limb-darkened disc in its
blackbody's colour, lighting its planets in that colour against the Sun's; a grey point where
nothing gives a size or temperature (5aac46d); the three-pixel floor and no halo; the camera held
at 0.05 AU or three radii, whichever is further, and a giant framed inside its neighbours' ring
(d1aa22e).

Measured on :4302 at 1600 by 1000 against published radii: Sun 1.0000 R☉ (card "1.00 solar
radii"); Proxima Centauri 0.1410, the archive's st_rad (0.154 in Boyajian et al. 2012); Sirius A
1.7943, derived, card "~1.8 solar radii, from colour and brightness" (1.711); TRAPPIST-1 0.1192
(0.119). The star's light: Sun (1, 1, 1), Proxima (1, 0.523, 0.165), TRAPPIST-1 (1, 0.443,
0.095), ups And (F8V) (0.899, 0.937, 1), Sirius (0.52, 0.666, 1), intensity pi in every one.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 13:34:38 +02:00
SenrokaiandClaude Opus 5.5 a70a7290f3 Test that the host matcher carries an archive row back from J2015.5, where the constant only was
6d81c45 set ARCHIVE_EPOCH to Gaia DR2's 2015.5 and tested the constant's value, through
propagateProperMotion; nothing tested that resolveHostStarId uses it. The review's mutant that
carried the matcher's queries back from 2016 passed 807 of 807, since the GJ 15 A fixture's decoy
sits 16″ away and half a year moves the query 1.5″ there.

A new case gives resolveHostStarId Barnard's star's archive row (the J2015.5 position and motion
the epoch test already uses) and three stars: Barnard's at the row carried back 15.5 years, and
decoys where carrying it back 16 and 15 years lands, 5.2″ either side at its 10.4″/yr. It must pick
Barnard's. Controls: the matcher carrying back from 2016, or from 2015, each fail it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 00:19:38 +02:00
SenrokaiandClaude Opus 5.5 69a052730f Test that the system view warms a host's planets by the luminosity the archive gives it
d94451e passes the host's surface luminosity, the archive's st_lum where it has one, to the
SystemOrbitsRenderer that classifies each planet, and no test looked at what the renderer got: the
review's mutants that handed it the derived luminosity, none, or the Sun's all passed 807 of 807.
Its commit says 544 planet temperatures move by more than 10 % and 98 planets change class with it.

The scene spec now enters Proxima and checks that Proxima b's marker carries the texture of the
appearance 0.00151 L☉ gives it (228 K, temperate), after checking that null and 1 L☉ each give
another class, so that the texture can tell them apart. Controls: the renderer given
starSurfaceOf(star, []).luminositySolar (the fixture has no measured band, so none), null, or 1
each fail it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 00:15:31 +02:00
SenrokaiandClaude Opus 5.5 15b8f2dff3 Say which stars sit at the Gliese catalogue's distances, about half of them no parallax at all
f8af0ec rewrote the neighbourhood note to say where positions come from, and it still said
"measured parallaxes" for everything but the archive's hosts. 313 HYG stars besides the Sun have
neither a Hipparcos nor a Gaia distance and sit at HYG's own, which for these rows is the Gliese
catalogue's resulting parallax: fetchStars says as much ("as often photometric as measured"), and
the review's cross-match with CNS3 (Gliese & Jahreiss 1991, VizieR V/70A; not repeated here)
found about 154 of them with a photometric or spectroscopic parallax, 130 within 25 pc — GJ 3522
drawn at 4.46 pc, 1000/224 mas, with no trigonometric parallax behind it. positionsNote now counts
the HYG stars without a distance error, the Sun aside, and names them. In the app on :4302 the note
reads "Positions from measured parallaxes; for the 313 stars only the Gliese catalogue places, from
its distances, about half of them photometric; for the 3,277 planet hosts only the NASA Exoplanet
Archive places, from its distances." and still fits the readout panel in four lines.

Test: a new star-readouts case counts a Gliese row and leaves the Sun out; the archive-only case
now expects the semicolon. Controls: dropping the Gliese clause, and counting the Sun among the
Gliese stars, each fail it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 00:10:58 +02:00
SenrokaiandClaude Opus 5.5 5ab4c5df89 Say a planet has no temperature because its star's luminosity or its orbit is unknown, not its star
The card and the body page said "Its host star is not in the catalogue" for every planet without
an equilibrium temperature. Over the shipped data that is 2 714 planets, and the host really is
missing for 27. 2 420 have no semi-major axis, and since 869635b gave a star no survey measured no
luminosity, 267 more have a host that is on the map: OGLE-2005-BLG-390L b's card said so inside its
own host's system. The text now names both things that can be missing without claiming which:
"No temperature could be derived: its star's luminosity or its orbit's size is not known." In the
app on :4302, /body/OGLE-2005-BLG-390L b and /body/PSR J1719-1438 b read it.

Test: the object card's missing-temperature case now expects the new sentence and checks the old
claim is gone. Control: putting the old sentence back fails it.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 00:07:18 +02:00
SenrokaiandClaude Opus 5.5 8f99335bae Give a luminosity below a hundredth of the Sun's two figures, so Proxima reads 0.0015 L☉ not 0.002
formatLuminosity printed three decimals from a thousandth to 1 L☉, which leaves one figure below
a hundredth. d94451e put the archive's own luminosity on the card, and Proxima's 1.51×10⁻³ L☉
(st_lum −2.821 ± 0.02 dex) read 0.002, 32 % over and six times the archive's error bar, while
8.9×10⁻⁴ just below the cut kept its two figures. Below 0.01 it is now two significant figures.

Over the 4 440 hosts exoplanets.json gives a luminosity for: 23 printed more than 10 % off it and
43 more than 5 % before (worst 32.5 %); none more than 5 % after (worst 4.4 %). In the app on
:4302, Proxima's card reads "Luminosity 0.0015 L☉".

Tests: quantity.spec now expects 0.0017 → "0.0017 L☉" and Proxima's figure → "0.0015 L☉", and
keeps 0.0523 and 0.523 at three decimals; star-readouts.spec and the scene spec now expect
"0.0015 L☉" where they pinned "0.002". Controls: three decimals below a hundredth, and two figures
reaching up to 1, each fail the named test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 00:04:47 +02:00
SenrokaiandClaude Opus 5.5 95ffb009a2 Tint each star in the field the colour its own disc is drawn in, a blackbody at its temperature
4191b70 carried BP−RP to the dwarf's B−V before the field's tint ramp read it, and said the Gaia
stars had been tinted redder than their own disc in the system view. They had been paler: the ramp
was white at B−V 0.8, a K0 dwarf, where a blackbody against the display's D65 is white near 6 500
K, B−V 0.44, and its red end, (1, 0.6, 0.35), was paler than an M dwarf's disc. After it 245 850 of
the 376 660 BP−RP stars were tinted bluish, 227 797 of them while their disc was warm. The field
now takes blackbodyColor at effectiveTemperatureK, the same function and the same temperature the
disc is drawn with, so a giant is tinted at its type's temperature too.

Over the shipped catalogue: stars bluish in the field with a warm disc 227 797 → 0, bluish at all
245 850 → 17 931, mean RGB distance from each star's field tint to its disc 0.250 → 0.001 (what is
left is the tint being cached at the nearest 10 K, which moves no channel by more than 0.0014). In
the app on :4302, field against disc after entering each star: Gaia DR3 6361559602963567744 (BP−RP
0.882, 5 543 K) (0.974, 0.982, 1) → (1, 0.854, 0.764) against (1, 0.854, 0.765); Gaia DR3
2026408043220034176 (1.84, 3 850 K) (1, 0.793, 0.664) → (1, 0.629, 0.34), the disc's own; HD 13531
(G0, B−V 0.70) (0.971, 0.979, 1) → (1, 0.86, 0.779), its disc's.

A blackbody per star cost 100 ms, and the scan of the table rows another 70, so the tint is cached
per 10 K and the table is bisected. Building the star field over the whole catalogue in the app
took 176-196 ms before and 151-159 after, four runs each.

Tests: a new case tints a G2 dwarf warm, exactly its 5 770 K blackbody, and Antares at the
temperature its type gives; the BP−RP render test now also checks an M0's blackbody. Controls: a
giant tinted at its colour's temperature, the tint taken against a bluer white than the disc's,
and a cache a hundred times too coarse each fail the named test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 00:00:43 +02:00
SenrokaiandClaude Opus 5.5 a8f394cf57 Read a giant's temperature off its type as well as its correction, so a radius has one source
d097f4b gave a giant its type's bolometric correction but left its temperature at the dwarf its
colour reads as, and the radius drawn from the two paired a correction for one star with the
temperature of another. The M giants stayed too cool (610 of them at a median 3 275 K, Antares
3 019 against Ohnaka et al.'s 3 660), and a hot giant behind dust got a 30 000 K star's correction
at the temperature of an A star: Menkib, O7.5 Iab at B−V 0.02, was drawn at 9 517 K and 95 R☉,
Alp Cam, O9.5 Ia, at 338, where 14 and 21 are published. Rigel went from 81 to 102 R☉, Alnilam
from 57 to 108.

giantSurface now reads both off the type: G to M giants off van Belle et al.'s (2021, table 8)
interferometric scale, fitted to 191 giants from G1 to M7.75 III, with the correction the dwarf
sequence has at that temperature; O to F giants off the dwarf of their type, for which the table
gains Mamajek's O3 to O9.5 rows (without colours, which do not tell O types apart); carbon and S
stars, which no row reads and which got the Sun's −0.06 at 2 420 K, off the medians of Bergeat et
al. (2001): 2 990 K over the 441 stars of their table 10 and −2.83 over the 383 with a V magnitude,
counted again from VizieR here.

On the shipped catalogue (drawn radius in R☉, before → after, published): Antares 690 → 410 at
3 730 K (680; its luminosity from V is 0.4 dex under Ohnaka's), Aldebaran 48.5 → 44.0 (44.2),
Arcturus 22.5 → 24.1 (25.4), Menkar 160 → 103, Gacrux 118 → 73, Rigel 102 → 67 (74.1), Alnilam
108 → 33, Menkib 95 → 6.9 (14, the dust still dims it), Alp Cam 338 → 31, La Superba 133 → 311
(315) and 544 → 6 977 L☉ (8 090 from Bergeat's bolometric magnitude), 19 Psc 130 → 305 (295).
The 610 M giants now sit at a median 3 644 K (p10 3 386, p90 3 816). Against their own radii
before, the O giants' fall to a median 0.08, the B giants' to 0.62, the M giants' to 0.68, and the
K giants' rise by 8 %. It is not better everywhere: Pollux goes from 8.6 to 10.1 against 8.8,
119 Tau from 700 to 326 against 587, and Mintaka and Alnitak, placed by Hipparcos at 212 and 226
pc where they are about 380, come out 8.8 and 11.8 against 13 to 20.

Tests: the giant case in stellar.spec now checks Antares's temperature against Ohnaka's, and
Aldebaran (to a tenth) and Rigel (to a fifth) against their interferometric radii; new cases give
Menkib its type's 36 100 K and a radius within 2.5 times the published one, and La Superba a
luminosity within a fifth of Bergeat's and 2 990 K; spectral.spec covers dwarfSequenceAtType. The
scene's supergiant case now expects Antares at 350-480 R☉ where it pinned 600-760. Controls:
the luminosity or the temperature ignoring giantSurface, G-M giants read as the dwarf of their
type, their correction taken off the type instead of their temperature, O giants through the
textbook colour clamped at B0, the type index off by one subclass and carbon stars unhandled each
fail the named test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:51:20 +02:00
SenrokaiandClaude Opus 5.5 06b4ff64b5 Read a white dwarf past the table's blue end at the temperature white dwarfs of its colour have
31e0c04 clamped an untyped star bluer than BP−RP −0.12 to the table's B9 row, so every one of the
110 white dwarfs within 50 pc was drawn at 10 700 K. Gentile Fusillo et al. (2021, MNRAS 508, 3877)
fit 104 of them at 14 266 to 39 304 K, and the radius their mass and gravity give was a median
0.65 of the one drawn. Past the table's end, dwarfSequenceAtColor now reads BP−RP off the median
pure-hydrogen temperature they fit in bins of ±0.025 around −0.15 to −0.40 (15 369 to 28 585 K,
counted again from the cross-match: 27, 24, 22, 15, 10 and 2 stars), and the correction and G−V
off the table's own rows at that temperature, through a new dwarfSequenceAtTemperature that
temperatureToColorIndex now shares.

Against GF21's R = sqrt(GM/g) over the same 104, the drawn radius goes from a median 1.53 (p10
1.33, p90 1.96) to 0.96 (0.94, 1.05), and the temperature from 0.59 of theirs to 1.00 (0.88,
1.02). Gaia DR3 6791196382856581376 is now 19 251 K and 0.0120 R☉, against their 19 205 K and
0.01245.

Tests: stellar.spec's −0.25 case now expects 19 012 K where it pinned 10 700, and a new case gives
that white dwarf its radius to within a fifth; spectral.spec reads −0.15, −0.13 and −0.6, keeps
the red end and B−V's blue end at their rows, and covers dwarfSequenceAtTemperature. Controls:
no white-dwarf branch, the bin's temperature without interpolating, B9's correction kept at the
new temperature, and the temperature read the wrong way round each fail the named test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:38:16 +02:00
SenrokaiandClaude Opus 5.5 18faa6d0b2 Classify a star for the rows that list it, not every star each time the index is built
The search index and the route index gave every one of the 455 571 stars a subtitle up front
through spectralClassification, which filtered the dwarf table afresh on each call; the star
field's tints read the same table once per BP−RP star. Both indices now carry the star itself
and classify it only for the rows shown (entrySubtitle): eight search results, a few route
options. The two filtered columns of the table are built once.

Node, over the shipped catalogue, five runs: classifying every star 121-167 ms before, 56-62
after hoisting the table alone; reading the sequence at every BP−RP colour 187-216 ms, now
111-127. In the app on :4302, two cold loads each, the long task when the Search tab opens was
264-380 ms (median 280) before and 164-276 ms (median 171) after; the longest boot task 863 and
875 ms before, 654 and 741 after.

Tests: the search spec checks its index holds no classification and the row still reads
"Star · ~M8"; the scene spec now reads the route options, and checks its index holds none either.
Controls: classifying every star in the search index, doing so in the route index, and route
options printing the index's subtitle each fail the named test.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:30:53 +02:00
SenrokaiandClaude Opus 5.5 d449214309 Stop calling WASP-108 b imaged, and stop saying no map exists of an imaged exoplanet
48fd6fd took the archive's ima_flag as it stood, so WASP-108 b's card said it had been imaged as a
point of light beside its star. It is a transiting hot Jupiter (period 2.676 d, 0.04 AU out, 0.15 mas
at 258.8 pc). Its flag comes from Bohn et al. 2020 (A&A 635, A73), a VLT/SPHERE survey of transiting
planets' host stars, which imaged a 0.35 solar-mass companion 0.124" from WASP-108, not the planet.
The imaged query now also asks for tran_flag=0. The archive flags exactly one transiting planet as
imaged (queried today: WASP-108 b); with it left out the list has 101 names, the old 102 less that
one, and still above the validator's floor of 95. The new URL is cached under its own name, and
exoplanets.json, regenerated by the full ETL, changes by that one record's field and nothing else
(checked record by record against HEAD).

build.ts now fails if WASP-108 b is marked imaged. The count cannot see a false positive, and its
record carries neither a period nor an axis, so no separation check could. Control: the full ETL on
the old query (its cache still present) fails with "WASP-108 b is marked as imaged; it transits, and
only a companion star beside it was imaged (Bohn et al. 2020)."

The imaged sentence ended "and no map of it exists". Luhman 16 b, one of the 101 and a brown dwarf,
was mapped by Doppler imaging (Crossfield et al. 2014, Nature 505, 654). It now reads "and no map of
it is used here", which holds for all of them; the doc comment names Luhman 16 b. Control: the old
sentence fails "says a directly imaged exoplanet was seen as a point of light" only (1 failed, 843
passed of 844). Live on :4301: WASP-108 b and Kepler-22 b read "no image of this world exists";
Luhman 16 b and HR 8799 b read the new sentence.

48fd6fd missed a third copy of the claim it corrected: the body page's comment still said every
exoplanet gets a derived surface "since none has ever been imaged". It now says none has had its
surface imaged, as planet-appearance.ts and the README do.

A correction to 48fd6fd's message: HR 8799 b, c and d are Marois et al. 2008 (Science 322, 1348),
and e is Marois et al. 2010 (Nature 468, 1080), not "b to e (Marois et al. 2008)".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:23:11 +02:00
SenrokaiandClaude Opus 5.5 936d1c01f8 Leave a system outwards from wherever the camera stands, and test that the scene frames the furthest it draws
Leaving a system flew the camera to a fixed 400 AU. Since c45d916 frames the Sun's system on Eris's
97.7 AU aphelion, a phone held upright arrives 508 AU out, so leaving drew the system 21 per cent
nearer during the 0.9 s exit (review, 390x844: 507.9 -> 400.0 AU). The exit now flies to 400 AU or
half as far again as the camera already stands, whichever is further. Measured live on :4301, the
distance from the Sun through the exit, first and last frame:

  390x844    507.9 -> 761.8 AU   (was 507.9 -> 400.0)
  360x780    508.5 -> 762.7
  768x1024   312.9 -> 469.3      (was 312.9 -> 400)
  1600x1000  234.7 -> 400.0      (unchanged)

and never nearer in between. The swap puts the camera at GALAXY_APPROACH_DISTANCE_PC whatever the
exit distance, so only the animation changes.

No test checked that the scene hands outermostRadiusAu to the framing: framing on the 67.9 AU
semi-major axis instead, which on a square window puts Eris off screen on arrival, passed all 841
tests. The scene spec's fixture held Earth alone. A describe now adds Eris (a = 67.934, e = 0.4382):
- "frames the furthest the system draws" requires the settled camera to stand at
  systemFramingDistanceAu(outermostRadiusAu) from its target, 234.7 AU at aspect 1.
- "leaves the system outwards even from a phone's framing" enters at aspect 390/844, then samples the
  camera each frame of the exit until the swap: never nearer, and further at the end.

Controls, each run on the full suite:
- outermostRadiusAu -> maxTopLevelSemiMajorAxisAu in the scene fails both (2 failed, 842 passed);
  the second fails too because the arrival is then under 500 AU.
- Math.max -> Math.min in the exit (back to 400 AU) fails the exit test only (1 failed, 843 passed).

The framing spec's fit() said it was "what the scene actually composes"; it frames the ring only, so
its comment now says it is the grid's half and where the aphelion is tested.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:17:00 +02:00
SenrokaiandClaude Opus 5.5 f6bb2b9584 Pin the 1972 hand-over to the leap seconds from the later side too
The test named for the hand-over caught the switch moved earlier and passed with it moved up to six
months later: both samples round midnight then fall on the polynomial (a step of about 0), the last
day of 1971 still reads 42.2485 s, and the 1972-06-30 = 42.184 check only sees a move past June.
Such a switch leaves TT - UT up to 0.59 s high through the first half of 1972. The test now also
requires 1 January 1972 itself to read the table's 42.184 s, the 10 s TAI - UTC began with plus
32.184.

Control: the switch moved to JD_1972 + 120 now fails "hands over from the polynomial to the leap
seconds at the start of 1972" only (1 failed, 843 passed of 844); before, the suite passed 841 of 841.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:16:48 +02:00
SenrokaiandClaude Opus 5.5 83dc46416b Test an exoplanet's aphelion in the framing radius and a derived surface's white, and give Earth's old TDB error as 8.6 degrees
Two lines the review found unguarded, each now held by a test that fails without it:

- outermostRadiusAu takes an exoplanet's eccentricity as well as a solar-system body's. c45d916 said
  303 of the 1 190 exoplanet systems have an aphelion past their grid ring, but both tests built the
  system from a BodyRecord. The new case is HD 20782 b (a = 1.3649 AU, e = 0.95), the most eccentric
  of them, whose aphelion is 1.66 times its 1.6 AU ring. Control: feeding eccentricity 0 for
  exoplanets fails "reaches an exoplanet's aphelion too" only (1 failed, 843 passed of 844).
- A derived surface resets its marker to white once painted, as a photograph does. Without it every
  exoplanet, the five Uranian moons, Proteus, Nereid, Hyperion, Eris, Haumea and Makemake would show
  their texture multiplied by the kind's flat colour. "paints them after the system is built, one a
  task" now asserts the exoplanet magenta before and 0xffffff after. Control: deleting
  material.color.set(0xffffff) on that path fails that test only (1 failed, 843 passed).

The AD 1000 Earth test's comment said the IAU W taken at TDB left the drawn face 6.6 degrees off.
6.6 is only the turn ΔT adds (1 572 s at 360.9856 deg/day); it adds to the W's own lead, so the
face is 8.57 degrees off. Measured here by putting Earth back on the IAU W at TDB in the renderer:
"expected -8.565166921766826". The 2.3 degrees the comment gives for the old code is the W at
UT + 69.184 s; at UT itself it is 2.0, and the comment now says both.

cbe4908's table also gave the 2025-06-01 12:00 row as "+0.06 before, -0.003 after". Two reviewers
measured the same Horizons point (1.579501 E) at +0.087 before and +0.0034 after: the row should read
+0.09 and +0.003. The message cannot be changed without rewriting history, so it is restated here.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 23:16:40 +02:00
SenrokaiandClaude Opus 5.5 acc4b928f2 Say that Makemake's day is known only to a factor of two, citing both readings
f655a4c kept Makemake's SBDB period, 22.83 hours, saying "nothing later overturns it", a reading
its author had not checked. The SBDB flags that period as Eris's was ("may be wrong by 30 percent
or so"). Hromakina et al. 2019 give 22.8266 h as the double-peaked period a "possible lightcurve
asymmetry suggests", of a light curve that repeats every 11.4 h. Kiss et al. 2024 (arXiv:2410.22544),
with TESS and Gaia, find the 11.401 +/- 0.076 h single peak again, "cannot confirm that the
double-peaked 22.8 h is Makemake's true rotation period", and take 11.4 h as their default.

Nothing is changed in what is drawn: the literature does not settle which it is, and 22.83 stays as
the SBDB's. The Makemake spec now cites both papers and says the drawn day may be twice the real
one, and the renderer's comment no longer calls the three dwarf planets' periods known.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:50:29 +02:00
SenrokaiandClaude Opus 5.5 4cd08ee324 Credit the IAU W on the three moons whose orbits take terms from it, guard Tethys's, and say what Mimas's lock ceiling is
Since f8ee3ac, Mimas, Tethys and Phobos move by terms taken from their IAU W in NAIF's pck00011:
Mimas's -44.85 degree S5 term, Tethys's +2.23 on the same angle, and Phobos's tidal quadratic,
which also re-centred its M0 (91.059 to 94.239) and n. Their cards still credited only "JPL SSD
satellite mean elements". They now read, for Mimas, "JPL SSD satellite mean elements, epoch 2000
Jan 1, with the orbital terms of its IAU W (NAIF pck00011), within 7.5 degrees of Horizons from
1950 to 2100"; Tethys and Phobos likewise (0.3 and 1.3). build.ts requires any moon carrying such
terms to name the kernel. Control: the full ETL with the old card fails with "Phobos's orbit
carries terms taken from its IAU W, and its card ... credits only the table."

Tethys's half of the libration had no guard. Without its term it strays 2.09 degrees from Horizons
over 1950-2100 against 0.28 with it, under the general 3-degree ceiling, and its card rewrote
itself as "within 2.1"; no unit test loads bodies.json. Tethys now has its own track ceiling of
0.5 degrees. Control: the full ETL without Tethys's orbitFromW fails with "Tethys's mean elements
put it up to 2.09 degrees from Horizons ... (at most 0.5 expected)".

The lock ceiling's comment said Mimas's 10.15 degrees was "physical libration, which W carries and
Horizons shows as 5 to 9 degrees". Neither holds: Mimas's measured physical libration is 0.84
degrees (Tajeddine et al. 2014), W carries no such term, and Horizons, on the same W against its
integrated orbit, runs from -2.7 to +12.7 degrees over 1950-2100 (the review's scan every 20
days). The drawn face's 2.5 to 10.15 is the IAU's W and JPL's mean longitude disagreeing by about
6.3 degrees, W turning 6.0e-5 degrees a day faster than the row's n (381.9945550 against
381.9944948, 3.3 degrees over the span), and 2e = 2.3 degrees of eccentricity. The ceiling itself
is unchanged.

The baseline ETL from the cache passes and changes bodies.json on those three cards only.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:50:21 +02:00
SenrokaiandClaude Opus 5.5 48fd6fd0e5 Stop telling the reader that the hundred directly imaged exoplanets were never imaged
Every exoplanet card without a map ended "Not an observation — no image of this world exists.",
and 395b613 wrote that rule into a comment ("Only an exoplanet has never been imaged") and a test.
The NASA Exoplanet Archive flags 102 planets as detected by imaging (ima_flag), all 102 of them in
exoplanets.json: HR 8799 b to e (Marois et al. 2008), bet Pic b, 51 Eri b, AF Lep b, and bet Pic c
and eps Ind A b, found by radial velocity and imaged since. The review read the sentence on the
live pages of HR 8799 b, 51 Eri b and bet Pic b.

The ETL now asks the archive for those names in a query of its own, cached apart from the main
table so the other 6 252 planets stay on the snapshot they were built from, and carries
`imaged: true` on the matching records. exoplanets.json changes by that field on 102 records and
nothing else (compared record by record). Their cards now end "Not an observation — it has been
imaged only as a point of light beside its star, and no map of it exists."; the rest keep "no
image of this world exists". The provenance comment and the texture catalogue's comment say which
is which.

Checked live on :4301: HR 8799 b and eps Ind A b carry the new sentence, Kepler-22 b the old one.

Tests: body-view-model.spec 'says a directly imaged exoplanet was seen as a point of light, not
that no image of it exists'; the old test is renamed 'says an exoplanet the archive does not flag
as imaged has no image'. Unit controls, each failing that test only (1 failed, 840 passed): the
provenance ignoring the flag; the view model dropping it. build.ts now requires at least 95
imaged planets (measured 102); control, the full ETL with the join made on the host's name
instead of the planet's, fails with "Only 0 exoplanets are marked as imaged".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:50:04 +02:00
SenrokaiandClaude Opus 5.5 ff744a00de Place a naked-eye star HYG gives no distance for by its Hipparcos parallax, where that is 2.5 times its error
c64eea0 left out 41 naked-eye stars "because neither survey gives them a distance". Hipparcos does:
HYG's distances are 1 000 over van Leeuwen's 2007 parallaxes, which the ETL already downloads for
their errors, but HYG writes its 100 000 pc placeholder for every parallax under 1 mas whatever its
error, while keeping far less certain ones above it (Alnilam at 1.65 ± 0.45 mas is drawn). 30 of
the 41 have a positive parallax in the new reduction and 7 have one at least 2.5 times its error:
HD 74180 at 0.67 ± 0.16 mas (4.2 σ), Mu Cep at 0.55 ± 0.20.

hipparcosDistancePc (star-merge.ts, with HYG's placeholder constant moved beside it) keeps HYG's
distance and, where it gives the placeholder, takes 1 000 over the parallax when that is 2.5 times
its error; fetchHipparcosParallaxErrors now returns the parallax with its error. From cache the ETL
keeps 73 563 HYG rows against 73 556 and publishes 455 571 stars; the seven are Alp Cam (1.4 to 3.0
kpc), Psi-1 Aur, HD 74180 (1.2 to 2.0 kpc), HD 86352, HD 96918, Mu Cep (1.3 to 2.9 kpc) and HD
217476, each printed as the range its parallax's error gives. The other 34 stay out: no parallax,
or one within 2.5 times its error of zero. Parallax distances printed as ranges go from 1 109 to
1 116; the validators hold.

Controls, each failing its named test: placeholder rows given no distance, and any parallax 1.25
times its error placing a star (1 of 807 each).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:45:12 +02:00
SenrokaiandClaude Opus 5.5 8c3a86097c Place a star at whichever of its two distances is the more precise, not at Gaia's regardless
placementDistancePc took Gaia's distance wherever the cross-match gave a usable one, and its
docstring and c64eea0 called that "the better measurement", adding that Gaia saturates on the
brightest stars "so those sit at their Hipparcos distance". For 273 of the 88 781 HYG stars with
both, Gaia's relative error is the larger, 257 of them naked-eye and 38 by more than twice: Eta Leo
was drawn at Gaia's 556.6 pc ±17 % against Hipparcos's 389 pc ±6.2 %, Schedar and Tarazed at
Gaia's though both have Gaia G of about 2.

placementDistancePc now takes both relative errors and picks the smaller, Gaia's as before when
either is missing; fetchStars gives the placed star the error and the Gaia-distance flag of the
distance it took. The merge's combine keeps the Gaia entry's direction, and now takes the other
entry's distance with its error where that is the more precise, so a bright star Gaia's main query
also holds lands at its Hipparcos distance too. Gaia still wins for the rest, whose parallaxes are
some fifty times more precise.

From cache: 424 stars move, 386 of them naked-eye; HYG rows at Gaia's distance 58 379 -> 58 109 and
HYG stars flagged so 8 129 -> 8 095. Eta Leo 556.6 -> 389.1 pc, Tarazed 178.9 -> 121.1, Imai 139.5 ->
105.8, Schedar 71.0 -> 70.0, Alphecca 23.7 -> 23.0, each now "±" its Hipparcos error. Where the two
disagree by more than 5 σ (21 stars, Iot Gem 11 σ), one of the formal errors is wrong, and this
takes the smaller one at its word. The validators pass unchanged.

Controls, each failing its named test: the placement ignoring the errors, the merge keeping Gaia's
distance whatever the errors, and taking the distance but not its error (1 of 805 each).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:37:35 +02:00
SenrokaiandClaude Opus 5.5 23547defe0 Read an archive host's colour off the dwarf sequence at its temperature, and say it was not measured
For an archive-placed host with a temperature and no B magnitude, fetchExoplanets took B−V from
Ballesteros' blackbody fit, which runs 0.1 to 0.2 redder than Pecaut & Mamajek's dwarf sequence
below 3 800 K, and the luminosity then read its correction off that sequence at that colour: 3 500 K
came back as 3 102 K with a correction 1.15 magnitudes too large, anything under about 3 170 K was
clamped to B−V 2.00, and the card printed it as a measured "Colour B−V 2.00". CFBDSIR
J145829+101343, a 580 K brown dwarf, read "Spectral type ~M6, from colour".

temperatureToColorIndex now reads the table itself backwards, interpolating B−V between the two
types the temperature falls between, so the temperature and correction read back off the colour
are the table's at that temperature; it has no answer outside 2 420 to 31 400 K. The colour is
flagged colorFromTemperature, a fifth bit in the photometry byte (the format, README and the ETL's
round-trip check follow), and the card prints it "B−V 1.66, from its temperature", marked derived.

From cache: 57 archive stars change colour; 54 carry the flag and 3, CFBDSIR J145829+101343 among
them, now have none. For the 47 of them the archive gives a luminosity, the one derived from
magnitude and colour moves from a median 0.228 dex off it to 0.124; Kepler-445 (3 157 K) from
0.0282 L☉ to 0.0080 against the archive's 0.0079. Its colour goes from 2.00 to 1.67. The card shows
the archive's luminosity where it has one since earlier on this branch, so this is the figure used
for the rest and for their radii.

Controls, each failing its named test: the nearest hotter row taken without interpolating (2 of
803 failed), no refusal outside the table, the flag not encoded, and the card calling the colour
measured (1 of 803 each).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:29:09 +02:00
SenrokaiandClaude Opus 5.5 c45d9160e3 Frame the Sun's system on Eris's aphelion, the furthest it draws, not on the grid ring inside it
The scene framed the grid's outer ring, sized from the largest semi-major axis, and two comments
said the ring was "always the wider of the two, by construction". That held until Eris came in:
its a = 67.93 AU gives an 80 AU ring, but with e = 0.438 its orbit reaches 97.7 AU, and Eris is
95.5 AU out now. The 12 per cent margin protected the ring, not Eris. The review measured Eris's
orbit at 0.982 of the half-width on a 390x844 phone (3.5 px from the edge), 0.987 on 1000x1400,
and on a 1000x1000 window Eris's marker at NDC 1.002, off screen on arrival.

SystemOrbitsRenderer.gridOuterRadiusAu becomes outermostRadiusAu: the ring, or the largest
top-level aphelion a(1 + e) where that runs past it. The scene frames that. Some orbit runs past
its ring in 303 of the 1 190 exoplanet systems too (counted on exoplanets.json), and they are
framed the same way. The 500 AU ceiling rises to 600: the aphelion needs 508 AU on a 390x844 phone,
and 600 holds it with its whole margin down to an aspect of 0.39. The comments are corrected.

Measured in the app on :4301 after entering the Sun, Eris's drawn orbit, largest |NDC x| over its
129 vertices (review's figures before):
  390x844    camera 507.9 AU  0.804  (0.982)
  1000x1400  camera 328.5 AU  0.805  (0.987)
  1000x1000  camera 234.7 AU  0.812  (1.004, marker off screen)
  950x1000   camera 247.0 AU  0.810
  1600x1000  camera 234.7 AU  0.508  (0.627)
No orbit vertex of Neptune, Pluto, Eris, Haumea or Makemake is off screen at any of them. The
cost: inner bodies arrive smaller, the landscape camera 235 AU out instead of 192.

Tests: renderer 'reaches as far as an eccentric orbit goes past the grid: Eris's aphelion, 97.7
AU, not the 80 AU ring' (and the ring where every orbit stays inside it), and framing 'leaves
Eris's aphelion its whole margin in every window shape'. Controls, each failing its named test
only (1 failed, 839 passed): framing on the ring alone; the ceiling back at 500 AU.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:24:23 +02:00
SenrokaiandClaude Opus 5.5 f82b5e1c74 Hold the published catalogue to what its host radii, distance errors and Gaia-distance flags come to
Three things the branch added could vanish from the data with every check passing, as the review
showed with guarded ETL mutants: dropping st_rad or st_teff from each planet left 0 of 6 354
carrying their host's radius or temperature, storing Gaia's parallax_error in milliarcseconds
rather than over the parallax changed 431 464 distance readouts, and dropping the flag fetchStars
sets relabelled 8 129 HYG stars placed at Gaia's distance "HYG". The round trip compares decoded
with encoded, and the counts of missing bands and errors do not look at what the values are.

validateExoplanets now requires 90 % of planets to carry their host's radius and temperature
(measured 6 030 and 6 054 of 6 354). validateStars requires the median relative error of the
distances at Gaia's to be under 1 % (measured 0.33 %), at most 1 % of stars to have a parallax
distance with an error of a fifth or more (measured 1 109, 0.24 %; the archive's, which are on the
distance and never ranged, are left out), and at least 6 000 HYG stars flagged at Gaia's distance
(measured 8 129). Figures from an ETL run from cache on this branch.

Each proved by a guarded mutant in a scratch copy of the ETL, run from the cache, failing with its
own message: host radius dropped ("Only 0 of 6354 exoplanets carry their host's radius and 6054 its
temperature"), host temperature dropped ("6030 ... and 0"), the Gaia error left in mas ("The median
error of Gaia's distances is 1.92 %"), the same with the median check waived ("17689 parallax
distances have an error of a fifth or more"), and the flag dropped ("Only 0 HYG stars are flagged
at Gaia's distance"); a no-op edit completed. No ceiling is loosened.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:20:38 +02:00
SenrokaiandClaude Opus 5.5 6d81c45f45 Carry the archive's positions back from Gaia DR2's J2015.5, where it publishes them, not J2016
fetchExoplanets placed each star it adds from the Exoplanet Archive by carrying the archive's
position back sixteen years, and 4c8e4a0 said the archive publishes at Gaia's J2016. It does not:
its positions are Gaia DR2's at J2015.5 although it names the DR3 source. Barnard's star in the
archive, 269.4486144, 4.7379808, equals DR2 4472832130942575872 at J2015.5 to 1e-7°, and sits 5.2″
from DR3's J2016 place; the review found 66 of the 67 archive-placed stars moving over 100 mas a
year within 0.21 mas of their DR2 position and none within 1 mas of DR3's. The matcher's comment
made the same claim of HD 133131 and TOI-2459, whose positions are DR2's too.

host-star-matching.ts now exports CATALOGUE_EPOCH and ARCHIVE_EPOCH = 2015.5, the matcher carries a
query back by their difference, and fetchExoplanets uses the same two, so the epoch is written
once. From cache: only the 3 277 archive-placed stars move, 2 287 of them by more than a
milliarcsecond, 74 by more than 50 and TOI-2406 most, by 203 mas, half a year of its 405 mas/yr;
no planet changes host. Invisible at map scale; the point is that the constant and its comments
now say what the archive does.

Control: ARCHIVE_EPOCH back to 2016.0 fails "carries Barnard's star from the archive's position to
where Gaia DR3's goes, to a few milliarcseconds" (1 of 802), which puts the two 5.2″ apart. The
GJ 15 A matching fixture is now built at J2015.5 too. fetchExoplanets' use of the constant has no
test of its own; the ETL has no test harness.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:20:26 +02:00
SenrokaiandClaude Opus 5.5 3453cd5d9f Say which cards give how far their orbit strays, since Pluto's does not
The date field's description read "Each moon's and dwarf planet's card says how far its orbit
strays from 1950 to 2100." Pluto is a dwarf planet on its card, but it moves on Standish's planet
elements, and the ETL measures only moons and the SBDB bodies against Horizons: its card ends
"Orbit: JPL approximate mean elements (Standish), fit for 3000 BC to AD 3000." and gives no stray
figure. In bodies.json, Ceres (7.2), Eris (0.1), Haumea (0.4), Makemake (0.3) and every moon carry
one; Pluto does not.

The description now reads "AD 1 to AD 3000, where the planets' and Pluto's elements hold. Each
moon's card, and Ceres's, Eris's, Haumea's and Makemake's, says how far its orbit strays from 1950
to 2100." The CLOCK_WINDOW comment and the scene's note comment make the same distinction.

Test: hud-dock 'opens the date field on the clock's date...' asserts the new sentence. Control:
putting the old sentence back fails that test only (1 failed, 836 passed).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:18:13 +02:00
SenrokaiandClaude Opus 5.5 85cb66e63c Test that a photograph shows in its own colours once it reaches its body
Since 2d4b8a9 a photographed marker is built in its kind's flat colour (a planet's 0.55, 0.75, 1.0,
a moon's 0.75 grey, a dwarf planet's 0.8, 0.7, 0.55) and only showNextPhotograph sets it back to
white when the map goes on. The material multiplies its map by its colour, so without that one line
every photograph would be tinted: each planet's turned blue, Mars's red cut by 45 per cent. The
review's mutant that drops it passed all 835 tests; the photographs test only looked at the map.

The test now also reads each material's colour: the kind's colour before the image loads, and
0xffffff for both bodies once their maps are on. Controls, each failing that test only (1 failed,
836 passed): showNextPhotograph without the white reset; and the marker built white from the start.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:16:04 +02:00
SenrokaiandClaude Opus 5.5 20c34f9662 Test the 1972 hand-over to the leap seconds where it happens, and give the ΔT comment its measured joins
The continuity test sampled 1972 at 2451544.5 + (1972 - 2000) x 365.2425 +/- 0.01 d, which is JD
2441317.70 and .72; the switch is at the calendar's 1 January 1972, JD 2441317.5, so both samples
read the leap-second table (42.184 and 42.184) and the join was never compared. Moving the switch
two years early (a 1.99 s step in 1970) passed all 836 tests. The hand-over now has its own test:
the step across midnight must be under 0.1 s (it is 0.067: 42.2514 to 42.184), and the last day of
1971 must still read the polynomial's 42.2485 s. Control: the switch at JD_1972 - 730 fails that
test only (1 failed, 836 passed).

The polynomials' own joins, measured 1e-6 d either side: 0.251 s at 1600, 0.162 at 1700, 0.087 at
500, 0.088 at 1900, and under 0.06 elsewhere. 34ae803 said its pieces join within 0.1 s; they join
within 0.26 s, a step in NASA's published Espenak-Meeus coefficients, which the code copies as
they are. The test's bound is tightened from 1 s to 0.3 s to say so. Control: starting the
1600-1700 piece 0.5 s high (a 0.75 s jump, which the 1 s bound let through) fails it only.

Comments in constants.ts: TT - UTC from 1972 is 32.184 s plus TAI - UTC, the 10 s UTC started from
and the 27 leap seconds since (it read "the 10 to 37 of them"). The Moon's error when ΔT was held at
69 s is 0.21 to 0.26 degrees at AD 1000 and 1.44 to 1.79 at AD 1 depending on where it is on its
eccentric orbit, not a single 0.22 and 1.43.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:13:09 +02:00
SenrokaiandClaude Opus 5.5 62f81f2c43 Number the stars the archive places after their host's name, so a refresh keeps each one's id
4c8e4a0 numbered each star it adds from the Exoplanet Archive by its place among the unmatched
hosts, in pl_name order, and the refresh workflow re-queries the archive every Monday. One host
added or dropped ahead of another renumbers it: in the review, removing a single planet row
renamed 3 276 of the 3 277 ids, and a bookmark kept on Kepler-186 (1070001620) opened Kepler-1860
under Kepler-186's stored name. HYG's and Gaia's ids do not move between refreshes; the merge's own
comment says ids are meant to hold.

archiveStarId (host-star-matching.ts, beside the matcher the ETL already imports from there) hashes
the host name with FNV-1a into the 3.7 million ids between 1 070 000 000 and 2^30, and moves a name
whose id is taken to the next free one. The added stars are sorted by id before they are appended,
so the published list stays in id order. Measured: all 4 237 archive-hosted planets change host id
once (Kepler-186 is now 1073671518), none of the others; one of the 3 277 names was probed past a
collision, and one new id falls in the old 1070000000-1070003276 range, so a bookmark saved on that
old id would open the wrong star once. Dropping the same row from a copy of the cached answer and
rerunning the exoplanet step in a scratch copy of the ETL now leaves 3 276 of 3 276 ids unchanged.
The validators pass: no duplicate id, all under 2^30.

Controls, each failing its named test: the id taken from the order of arrival, and no probing past
a taken id (1 of 801 each).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:12:00 +02:00
SenrokaiandClaude Opus 5.5 cbe4908219 Turn Earth by the Earth Rotation Angle, so its lit face stays Horizons' at AD 1 as it is today
Earth was turned by its IAU W, taken at the clock's UT plus today's 69.184 s. That W is a straight
line fitted to the present: 360.9856235 degrees a day, which, once its pole's -0.641 degrees a
century in right ascension is counted, runs 6.3e-6 degrees a day slow of Earth's real turning. The
followsUt comment said the clock's date "already says how far it has turned"; it did not. Against
Horizons (observer quantity 14 from the Sun, TIME_TYPE=UT, Earth one light-time back) the drawn
sub-solar point was 2.3 degrees off at AD 1000 and 4.5 at AD 1.

Earth is now turned by the IERS Earth Rotation Angle (IERS Conventions 2010, eq. 5.15) at the
clock's date, counted from the node the IAU's W starts at, 90 degrees past the pole's right
ascension. The pole is unchanged. Drawn minus Horizons, in degrees:

  date                       before    after
  2025-06-01 12:00 (unit)     +0.06   -0.003
  AD 1000, JD 2086455 (unit)  -2.3    -0.001
  AD 1, JD 1721600 (unit)     -4.5    +0.051
  live app, :4301, same probe as the review's
    JD 2460900.25             +0.089   +0.005
    JD 2086300.5              -2.281   +0.010
    JD 1800000                -4.049   +0.056
    JD 1721450.75             -4.530   +0.072

At noon UTC on 1 June 2025 the Sun now stands over 0.52 W on the drawn sphere, where the equation
of time puts it at 0.53 W (0.43 W before).

TT_MINUS_UTC_DAYS had no other use and is removed; its comment also counted 37 leap seconds where
UTC has taken 27 on top of the 10 s it started from in 1972.

Tests: body-orientation.spec 'lights Earth's face where Horizons does at the far end of the clock
too: AD 1000 and AD 1' (within 0.15 degrees), and the renderer's AD 1000 Earth test now checks the
drawn face against Horizons instead of against the IAU W the old code used. Control: turning Earth
by its IAU W at UT + 69.184 s again fails both named tests (2 failed, 834 passed). The README says
which model turns Earth.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:09:54 +02:00
SenrokaiandClaude Opus 5.5 1a8e734651 Leave the dark nebulae out of the backdrop, whose sprites can only add light
c01d3ec read OpenNGC's addendum, which brought in its only two DrkN rows, C099 the Coalsack and
B033 the Horsehead; NGC.csv has none. classifyOpenNgcType mapped DrkN to 'nebula', so both were
drawn as the backdrop's nebula sprite: ff86b0, additive, at the faintest opacity and the 70 pc
minimum size, about 1.6° across. The review measured it adding up to +59 in red over the Coalsack
beside Crux, where the sky has a dark hole, and darkening no pixel, as an additive sprite cannot.

DrkN is now among the codes dropped, with the reason beside the map. fetchDeepSky from cache keeps
488 objects against 490, still 107 Messier objects and every required id; README's count follows.
On :4302 the served backdrop holds 488 objects and the scene 488 sprites, neither of them C099 or
B033.

Control: DrkN mapped back to 'nebula' fails "leaves out a dark nebula, which a sprite that adds
light cannot draw" (1 of 801).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 21:00:31 +02:00
SenrokaiandClaude Opus 5.5 0e9ab6ffb5 Fold the Gliese entries that move with a Gaia star up to 160″ away, where a minute left 39 twice
74b93a0 let a Gliese-only HYG row fold into a Gaia entry that moves with it up to a minute of arc
away, since Gliese's positions are off by that much. Its report counted only the 3-60″ residue.
Measured on the published catalogue with the merge's own motion and brightness rules, 39 Gliese
rows within 25 pc still had a bare Gaia entry moving with them 60 to 150″ away (32 within 100″,
none past 150); with every row shifted a quarter of a degree north or south, none did. The review
found 36 of them to be the same star under SIMBAD, three within 10 pc: GJ 3618 (LHS 288) at 4.49 pc
beside its Gaia entry at 4.83 pc 94″ away, GJ 1123 at 8.13 and 9.52, GJ 1001 at 9.60 and 12.31.

MERGE_COMOVING_ANGULAR_TOLERANCE_DEG is now 160″. The ETL from cache folds 62 046 entries against
62 002, leaves 11 510 HYG rows without a counterpart against 11 554, and publishes 455 564 stars;
within 10, 25 and 50 pc the map now holds 369, 5 523 and 40 877 against 372, 5 564 and 40 921
(GCNS: 312 Gaia sources within 10 pc). No Gliese row within 25 pc has a co-moving bare Gaia entry
3-300″ away any more. GJ 3618, GJ 1123, Gl 319C and GJ 3999A now sit on Gaia entries. One
exoplanet changes host id: LHS 475 b's Gaia entry took HYG's id with its description.

Not every name lands where SIMBAD would put it: Gl 319C takes the entry SIMBAD calls GJ 319 B, as
HYG's Gl 319B already sat on SIMBAD's C, and GJ 3999A takes the entry named GJ 4000B before, which
moves to the bare one beside it. Both systems go from one entry too many to one per star; the
names follow HYG's positions, which only identifiers could correct. The merge validators hold: 23
cross-catalogue pairs within an arcsecond, as before.

Controls, each failing its named test: the window back to a minute (2 of 801 failed), and 200″
(1 of 801).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:59:05 +02:00
SenrokaiandClaude Opus 5.5 150ec76bbd Say that a host's radius, temperature and luminosity come from the composite table alone
The comment on hostStarRadiusSolar and its two neighbours said they were read from "the planet's
default row first, then the composite table". The default-row query (TAP_COLUMNS in
fetchExoplanets.ts) asks for none of st_rad, st_teff or st_lum — the cached answer's columns end at
st_mass and disc_year — so host() always reads them from pscomppars, whose columns may each cite a
different reference: Proxima's 0.141 R☉ is the composite table's. It also said they were measured
where stellar.ts derives a luminosity, which held for the luminosity only once starSurfaceOf began
reading st_lum, earlier on this branch; it now points at starSurfaceOf. A comment, so there is no
test to fail.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:50:42 +02:00
SenrokaiandClaude Opus 5.5 4ebe663a84 Carry the Hipparcos parallax errors between weekly refreshes, as the Gaia answers already are
a81dd49 added a query of public.hipparcos_newreduction on the ESA archive, cached as
hipparcos-errors-<hash>.csv, and fetchStars requires it: a failed or short answer throws. The
refresh workflow carries only tools/etl/.cache/gaia-dr3-*.csv between runs, a glob that file does
not match, so every weekly run fetched its 117 955 rows live from the archive the cache exists to
spare, and an ESA outage would have failed the refresh even with every Gaia answer cached. Before
a81dd49 a warm cache meant no request to that archive at all.

The cache step now lists both globs. Its key gains "-hipparcos": actions/cache keys are immutable,
and an entry already saved under the old key would be restored without the new file and never
saved again. Checked with Node's path.matchesGlob against the local cache (gaia-dr3-54fdbc7a,
gaia-dr3-hip-785b92fc and hipparcos-errors-f846b045 match, the archive's own files do not) and by
parsing the workflow with PyYAML. A workflow file has no unit test to fail without the change.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:46:29 +02:00
SenrokaiandClaude Opus 5.5 08bf8b18a6 Test that a Gaia star with no measured band is still labelled Gaia's
describingCatalogue calls a star Gaia's when its source is gaia and its band is not V. 44 Gaia
sources in the shipped catalogue have no G (Gaia DR3 40091256260676736 among them), and nothing
tested them: narrowing the rule to band G, which would relabel all 44 "HYG" and count them as HYG
in the neighbourhood census, passed the suite. The existing test already builds such a star and
now checks its Source row as well.

Control: the rule narrowed to band G fails "says a stand-in magnitude was not measured, and leaves
out a colour there is none of" (1 of 797).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:43:51 +02:00
SenrokaiandClaude Opus 5.5 f8af0ecf6e List stars in search and routes by the type their colour gives them, and say where archive positions come from
5333be6 gave the star card an estimated type for the 383 695 stars the ETL files as "Unknown",
but search rows, the route search index and the current-star route option still printed that
literal: TRAPPIST-1 read "STAR · UNKNOWN" in search beside "Spectral type ~M8, from colour" on its
card, audit #17's own symptom. spectralClassification (spectral.ts) now gives the catalogue's type,
else the colour's marked "~", else nothing, and all three and the card's subtitle use it; a search
row with nothing to add prints its kind alone rather than a trailing " · ".

The neighbourhood note still read "Positions from measured parallaxes" after 4c8e4a0 placed 3 277
stars at the Exoplanet Archive's sy_dist, 343 of them without a usable parallax and 281 of those
past 1 kpc — microlensing hosts such as OGLE-2005-BLG-390L at 6.6 kpc, from a lensing model.
positionsNote now says so, with the count. Neither the note nor the census subtitle (audit #16) had
a test: putting back "Hipparcos · Yale Bright Star · Gliese" passed all 775.

In the app on :4302: the note reads "Positions from measured parallaxes, and for the 3,277 planet
hosts only the NASA Exoplanet Archive places, from its distances. Grid marks the galactic plane
through the Sun."; search reads "TRAPPIST-1 STAR · ~M8", "OGLE-2005-BLG-390L STAR", "Sirius STAR ·
A0M"; TRAPPIST-1's route option has subtitle "~M8".

The scene spec gains an archive-placed fixture star. Controls, each failing its named test: the
search row printing the raw type, keeping the separator with nothing after it, the route index
and the current-star option printing the raw type, the note back to parallaxes only, the subtitle
back to the old catalogue list (1 of 797 each), the note never counting the archive (2 of 797),
and the classification without its estimate (3 of 797).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:42:03 +02:00
SenrokaiandClaude Opus 5.5 4191b70e63 Tint a star measured in Gaia's BP−RP as the B−V of the dwarf of that colour
colorIndexToRgb maps a B−V onto the star field's tint ramp, and its one caller passed it every
star's colour index, whatever colorSystem said. BP−RP is the larger of the two for the same star —
0.823 against 0.65 for a G2 dwarf, 1.84 against 1.42 for an M0 (Pecaut & Mamajek) — so the 376 703
stars measured in it, 83 % of the catalogue, were tinted as later types than they are, and redder
than HYG's stars of the same type, and than their own disc in the system view.

A BP−RP is now carried to the B−V of the dwarf sequence at that colour (the table's own B−V
column, which DwarfSequencePoint now returns, clamped at its ends), then tinted as before. The
median Gaia colour, BP−RP 0.883, a G7 dwarf, read as a K2: its tint goes from (1, 0.972, 0.955) to
(0.975, 0.982, 1), the same as HYG's G7 stars.

Controls, each failing its named test: BP−RP read as B−V (2 of 792 failed), the star field not
passing the colour system (1 of 792), and the B−V taken from the wrong column (3 of 792).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:31:27 +02:00
SenrokaiandClaude Opus 5.5 fa52f6a818 Give an archive star's distance error as the error on the distance it is, not as a parallax range
formatDistance printed any error of a fifth or more as the range a parallax's error makes,
d/(1+e) to d/(1−e). A star the ETL places from the Exoplanet Archive carries the mean of sy_disterr1
and 2 instead, which the archive defines as one-sided errors on sy_dist in parsecs, and many of
those distances come from a lensing model with no parallax behind them. 129 of the 3 195 archive
stars with an error were printed as ranges the archive does not give: KMT-2016-BLG-1836L as 5.8 to
9.2 kpc, where the archive publishes 7 100 +800 −2 400 pc, and AT2021ueyL as 664 pc to 2.4 kpc
against 1 040 +740 −440.

The card now tells formatDistance when the error is on the distance (source exoplanet-archive), and
it keeps the ± at any size. Measured on the shipped catalogue: KMT-2016-BLG-1836L reads 7.1 ± 1.6 kpc,
AT2021ueyL 1.0 ± 0.6 kpc, EPIC 201170410 134 ± 43 pc, KMT-2016-BLG-0212L 6.3 ± 1.3 kpc. The ETL keeps
only the mean, so a lopsided interval such as KMT-2016-BLG-1836L's is shown symmetric; carrying both
errors would take a second column in stars-meta.bin. The doc comments on formatDistance and on
distanceError no longer say an archive distance is an inverted parallax.

Controls, each failing its named test: the error on the distance read as a parallax's (2 of 790
failed), and the card not saying it is on the distance (1 of 790).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:27:01 +02:00
SenrokaiandClaude Opus 5.5 d1aa22ed61 Frame a giant so its disc sits inside the ring its neighbours are named on
The system view names a star's neighbours on a ring at 0.74 of the view's tighter half-extent,
whatever the star. A giant was framed to fill the frame, 2.4 radii out, which the three-radius
closest approach then overrode, so it settled at 3 radii with its disc projecting to 0.758 of the
half-extent: in the app, Betelgeuse's disc was 379 px on a 1 000 px view against the 370 px ring,
and HD 39374 and HD 38118 were printed on it at about 1.3:1 contrast.

The star's term in the framing distance now places its silhouette, asin(R / d), at half the
tighter half-extent, which puts the camera 4.4 radii out on a 50° view. Measured on :4302 at
1600 by 1000: Betelgeuse settles at 13.9 AU (closest approach 9.5) with a 250 px disc and Antares at
14.1 AU; the nearest corner of any neighbour's name is 292 px from the centre, so none is on
either disc (it was two and one of them before). Closing in to the closest approach can still bring
the disc over the names; that is the viewer's choice, not the arrival's.

This also gives the star's term a job: at 2.4 radii it never exceeded the closest approach, so
dropping it changed nothing (the previous commit's one surviving control). Controls, each failing
its named test: the star left out of the framing (1 of 788 failed), the star framed to fill the
frame (2 of 788), and the disc taken as flat (1 of 788).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:23:43 +02:00
SenrokaiandClaude Opus 5.5 5aac46de08 Draw a star nothing gives a size or temperature for as a grey point, not as the Sun
The system view drew every star without a radius at the Sun's radius, and every star without a
temperature in the Sun's colour. PSR J1719-1438, a neutron star 10 km across, came out 1 R☉ wide,
wider than its planet's 0.0044 AU orbit, and b spent nine tenths of its orbit inside it; Procyon B,
a white dwarf of 0.012 R☉ with a type the parser does not read and no colour, was a Sun 81 times
too wide in the Sun's colour.

Such a star is now drawn at 150 km, under the three-pixel floor from anywhere the camera can go, so
the floor's point is what shows, and its disc keeps the photograph's own grey instead of the Sun's
tint. Its light stays white, which is the photographs' own light rather than a claim about the
star. 2 858 stars take this after the clamping in the previous commit, against 3 077 drawn at the
Sun's radius before it.

In the app on :4302: PSR J1719-1438's star is drawn at 1.7×10⁻⁴ AU (the floor, 168 times its
geometry) with b 0.00417 AU from its centre, outside it; Gl 280B at the floor, tint (1, 1, 1) and no
radius on its card; Proxima at 0.141 R☉, tint (1, 0.459, 0.135), light (1, 0.523, 0.165), card
"Luminosity 0.002 L☉" unmarked and "Radius 0.141 solar radii".

The scene's use of the star's surface had no test: every star in the scene spec was drawn at the
Sun's radius, and drawing all of them so, lighting planets white, tinting every disc as the Sun or
closing the camera to the Sun's clearance all passed. The spec now gives Proxima its planet's
archive row and adds Antares and Procyon B, and three tests enter them. Controls, each failing its
named test: every star at the Sun's radius (3 of 787 failed), an unmeasured one at it, the light
without the temperature, the closest approach for the Sun, the Sun's tint for a host, the Sun's tint
for a star without a temperature, and the card without the surface (1 of 787 each). Dropping the
star from the framing distance was not caught: its term, 2.4 radii, never exceeds the three-radius
closest approach the camera is clamped to, so it cannot change where the camera settles.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:13:22 +02:00
SenrokaiandClaude Opus 5.5 31e0c04fe1 Read a colour past either end of the dwarf table at that end, where the star has no type instead
dwarfSequenceAtColor answers null outside Pecaut & Mamajek's table, B−V −0.301 to 2.16 and BP−RP
−0.12 to 5.1, and effectiveTemperatureK then fell back on the type, which Gaia's stars do not have
and carbon stars' parser does not read. 219 stars with a measured colour got no temperature and so
no radius, and were drawn at the Sun's radius in the Sun's colour: 110 white dwarfs within 50 pc,
38 Gaia stars redder than BP−RP 5.1 (Gaia DR3 6439125097427143808, an ultracool dwarf 4.0 pc away),
HD 46687, La Superba and the other carbon stars, and an O8 star.

Past the table, the colour is now read at the row it is past (clampToTable), but only for a star
with no readable type: beside a type an off-table colour is more often the bad measurement — HD
49748 is G5 V at B−V −0.32 — so the type still wins there, as it did. The luminosity reads the same
point, so a star past the red end also gets the M8.5 row's G−V and correction. A type's own colour
past the table, which only O types have, is read at B0. Carbon and S stars (C, N, R, S) now count
as giants, so their correction stays their type's, not an M8.5 dwarf's −5.78.

Measured on the shipped catalogue: stars without a temperature 3 053 -> 2 834, without a radius
3 077 -> 2 858; all 292 stars with an off-table colour now have a temperature, against 73. Gaia DR3
6439125097427143808 is 2 420 K and 0.110 R☉ (M8.5 V: 0.104); the 110 white dwarfs a median 0.018 R☉
at 10 700 K (0.0013 to 0.034); HD 46687 212 R☉ at 2 420 K and La Superba 133; audit #16's Gaia DR3
5612323414549657984, k1 Pup, B6 V at BP−RP −0.15, 203 L☉ and 4.1 R☉ against 143 and none (FLAME
gives 336 and 3.49). The 2 851 stars left without a radius have neither a colour nor a readable
type, or no band.

Controls, each failing its named test: no clamp for an untyped star (2 of 784 failed), the clamp
winning over a type, an O type's colour unclamped, the luminosity off the unclamped sequence, and
carbon stars not counted as giants (1 of 784 each); clampToTable ignored (3 of 784).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 20:01:07 +02:00
SenrokaiandClaude Opus 5.5 dc7277f740 Say in the textures README that the mission mosaics' brightness is not albedo, as Iapetus shows
Iapetus's leading hemisphere has an albedo of 0.03-0.05 and its trailing one 0.5-0.6, about a
tenth. On iapetus.jpg, between 30 S and 30 N, the leading side (30-150 W) averages 83.4 of 255 and
the trailing (30-150 E) 108.2, a ratio of 0.77, measured here again; the USGS source gives the same
(83.3 and 108.1), so it is the mosaics' frame-by-frame contrast stretch, not the processing. The
README's Iapetus row checked only where Cassini Regio lies, and nothing said the brightness is not
albedo; it now does, with those figures. The map is not rescaled: no photometric model was applied
to any body, and one hemisphere's worth of scaling would be invented for this one.

Documentation only; no behaviour changes.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:58:52 +02:00
SenrokaiandClaude Opus 5.5 d93bb1ee2c Say that Pluto's tilt is checked against its own IAU pole, not against Horizons
The ETL's obliquity check, its failure message and the renderer spec's test name all compared
Pluto's drawn tilt with "the obliquity Horizons gives", as 1c86584 and cdf474b said too. Horizons'
Pluto page states none (grep -i obliq finds only the page's IAU76 frame note); the 119.6 degrees is
hand-entered in fetchSolarSystem.ts from the IAU WGCCRE 2015 pole (RA 132.993, Dec -6.163), which
with Pluto's orbit gives 119.609. So for Pluto the check confirms that the kernel's pole and the
sense of W were read as written, which it would still catch misread, but not the pole against a
second source.

The build.ts comment says so, its message names Pluto's reference as its IAU pole, and the spec's
test name and comment no longer attribute Pluto's tilt to Horizons. Labels only; no behaviour
changes.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:58:33 +02:00
SenrokaiandClaude Opus 5.5 98c4eb901f Credit the sources the solar system's orbits now come from, in the README and a search comment
Since 48319c3 and 1d42be2 no position comes from Horizons: the planets move on Standish's mean
elements (Table 2a/2b), the moons on JPL SSD's satellite table, Ceres, Eris, Haumea and Makemake
on the Small-Body Database's osculating elements, and every body turns by the IAU's rotational
elements from NAIF's pck00011. bodies.json's orbitSource values say so (9 Standish, 25 satellite
table, 4 SBDB, none Horizons). Horizons gives sizes, spins and the positions the ETL checks
against. The README still credited "Solar-system ephemerides: NASA/JPL Horizons", said the Sun's
bodies came "from JPL Horizons", listed fetchSolarSystem's source as "JPL Horizons / SSD", and had
Horizons reporting every element against the ecliptic, where the moons' are against a Laplace
plane or their planet's equator. The branch had edited the credits paragraph and left that line.
search-ranking.ts called the solar-system bodies "eighteen famous objects"; there are 38.

Documentation only; no behaviour changes.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:57:50 +02:00
SenrokaiandClaude Opus 5.5 a281f22f34 Measure every moon and dwarf planet against Horizons from 1950 to 2100, and say on its card how far it strays
The clock reaches AD 1 to AD 3000, but only the planets' cards named a span their elements hold
over; the 25 moons and the four SBDB dwarf planets gave a source and an epoch, though
BodyRecord.orbitSource is documented as "the span they hold over". And the worst offsets the ETL
stated came from twelve New Year's Days: Nereid's year is 360 days, so all twelve fell far from
its periapsis, where a mean ellipse is furthest out. The one date the ETL checked, 2025-01-01, saw
Nereid at 2.6 degrees; it reaches 11.19.

For each moon and each SBDB dwarf planet the ETL now fetches Horizons' ICRF vectors from 1950 to
2100, every other day (daily for Nereid, at an eccentricity of 0.75, and Hyperion, whose row's
eccentricity is a quarter of its real one: every other day gave it 22.14, daily 22.23), and
measures how far the mean elements stray, at the same TDB dates. The card appends it: "JPL SBDB
osculating elements, epoch 2026 Jun 9, within 7.2 degrees of Horizons from 1950 to 2100". Worst
offsets on the real catalogue: the Moon 2.62 (2010 March 27), Phoebe 2.58 (1969, where a comment
claimed "within 2.0"), Phobos 1.26, Mimas 7.43, Iapetus 10.34, Nereid 11.19 (2039 Nov 1),
Hyperion 22.23 (2055 Feb 26), Ceres 7.12 (1953); Io 0.07, Titan 0.06, Eris 0.06.

build.ts recomputes each from the same Horizons positions and fails if an orbit other than
Standish's names no span, if a card states less than it strays, or if a body passes its ceiling:
3 degrees, and Hyperion 23, Nereid 12, Iapetus 11, Mimas 8 and Ceres 8, each explained. The
2025-01-01 check stays for reading errors, its comment no longer passing one date's offsets off as
worst ones. The Sun's note says the moons' and those four's elements were checked from 1950 to
2100, and the date field's description that each card says how far its orbit strays over that span.
In the running app Ceres's, Phobos's and Nereid's cards end "within 7.2", "1.3" and "11.2 degrees
of Horizons from 1950 to 2100".

The CLOCK_WINDOW comment also had the calendars the wrong way at AD 1: proleptic Gregorian dates
are two days behind the Julian calendar there, level from AD 200 to 300, and ten days ahead by
1582. It now says so, and names Ceres's drift where it named Phobos's, which its orbit now carries.

Controls: the ETL measuring nothing fails ("Ceres's orbit ... names no span it holds over"),
rounding the stated figure down fails on Ceres (7.1 against 7.12), and Nereid held to the general
ceiling fails at 11.19; the note and the date field without the span fail their named tests.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:57:16 +02:00
SenrokaiandClaude Opus 5.5 d097f4b477 Correct a giant's light by its type, not by the cooler dwarf its colour reads as
3392f06 read every star's bolometric correction off the dwarf sequence at its colour, so a giant
got the correction of the cooler dwarf of that colour, which is larger. Antares, M1 Ib at B−V 1.87,
took an M5 dwarf's −3.26 and came out 172 023 L☉ and 1 516 R☉, a 7.06 AU sphere, against the 680 R☉
Ohnaka et al. (2013) measure; 119 Tau 2 838 against 587, Menkar 204 against 89.

isGiant (spectral.ts) reads luminosity class I to III off a type's primary component, or HYG's g
and c prefixes, and a giant keeps its type's correction. Drawn radius against the published one
(no planets, so derived), before and after: Antares 2.23 -> 1.01, 119 Tau 4.84 -> 1.43, Menkar 2.29
-> 1.80, Scheat 1.92 -> 1.42, Aldebaran 1.95 -> 1.10, Mirach 1.96 -> 1.27, 41 Com 2.14 -> 1.56;
Betelgeuse 0.76 -> 0.89. It is not better everywhere: Gacrux goes from 1.23 to 1.40 and Arcturus
from 1.02 to 0.88. 10 808 stars have a giant's type, 10 794 of them a colour. Against the archive's
own luminosity for the 130 giant hosts, the median error moves from 0.038 to 0.052 dex and the 90th
percentile from 0.246 to 0.204; 17 are off by over 1.5 times, against 19.

Controls, each failing its named test (1 of 781): the giant given the dwarf's correction, a giant
companion read as the primary, a IV read as a I, and the prefixes ignored.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:53:22 +02:00
SenrokaiandClaude Opus 5.5 2d4b8a98d5 Put each body's photograph on it one frame at a time, so entering the Sun's system no longer stalls
buildMarker gave every photographed body its map at once. A texture is copied to the GPU in the
first frame that draws it, and the 28 maps arrive within about 40 ms of each other, so that frame
copied some 20 megapixels of JPEG (seven maps at 2048x1024) through copyExternalImageToTexture: a
second long task of 135-162 ms about 1.25 s after entering, measured here four times on the
committed renderer (reviewers measured 160-210 against 85-100 without the 18 new maps). de34fff's
"adds no long task" was measured before those maps landed.

A photographed body now starts in its kind's flat colour, as a derived one does, and its texture
waits in a queue; each update() puts the first one that has loaded on its body. The copies are
spread one a frame, and all 38 bodies have their maps within half a second of the first. In the
running app, five fresh entries into the Sun's system at 1600x1000 left one long task of 52-66 ms
or none at all ([66], [52], [62], [], [56] ms, where the committed renderer gave [62, 149], [56,
135], [74, 162], [78, 162]).

Control: putting every loaded photograph on in one frame fails "puts them on their bodies once
loaded, one a frame".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:48:31 +02:00
SenrokaiandClaude Opus 5.5 d94451e203 Warm a host's planets by the luminosity the archive publishes for it, not one derived beside it
The ETL has carried each host's st_lum since 494fb56 and nothing read it: the card, the system
view's planet temperatures and the body pages all derived a luminosity from the star's magnitude
and colour. For 757 of the 4 440 hosts the archive gives one for, the two differ by more than
1.5 times, 667 of them stars the ETL placed from the archive's own V and B−V. Proxima read
8.9×10⁻⁴ L☉ beside the archive's radius and temperature, which imply 1.27×10⁻³; the archive gives
1.51×10⁻³, as Ribas et al. 2017 do.

starSurfaceOf now returns the luminosity with the radius and temperature, taken from the first of
the host's planets that gives one, as st_rad and st_teff already are, and derived only otherwise.
The system view lights its planets with it, the body page uses the same host rule, and the card
marks it derived only when it is. The derived radius still comes from the derived luminosity, so
its "from colour and brightness" stays true; only 3 hosts have st_lum and no st_rad.

Measured on the shipped catalogue against the parent commit: 544 of 3 639 planets with an
equilibrium temperature move by more than 10 %, and 98 change class. Kepler-186 f goes from a 292 K
rocky world to a 175 K icy one, LHS 1140 b from 152 K icy to 206 K temperate, LTT 1445 A b from
298 K rocky to 402 K scorched, Proxima Cen b from 200 to 228 K and d from 259 to 296 K.

starReadouts now takes the surface alone, which carries the luminosity. Controls, each failing its
named test: the archive's luminosity ignored (2 of 778 failed), called derived, the body page
warmed by the derived one, the body page reading the planet's own row only, and the card marking
a published luminosity derived (1 of 778 each).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:47:34 +02:00
SenrokaiandClaude Opus 5.5 6c0626ca38 Frame the Sun's system out to Eris on a portrait window, where Eris and Makemake arrived off screen
The arrival framing fits the grid's outer ring, which Eris (a = 67.93 AU) took from 40 AU to 80,
but its 200 AU ceiling was sized for Pluto's ring. At 390 by 844 the ring needs 416 AU and at 1000
by 1400 269, so both were clamped to 200: Eris arrived at NDC (2.08, 0.48) on the phone, with
Makemake at (-1.14, -0.25), and at (1.34, 0.48) on the tall window. The spec never saw it, its
solar system ending at Neptune.

The ceiling is now 500 AU, which frames the 80 AU ring at any aspect down to 0.385; the landscape
fit is unchanged. The window-shape test now includes the solar system out to Eris and a 390 by 844
phone. In the running app every top-level body is on screen on arrival: the camera at 415.8 AU on
390x844, 269.0 on 1000x1400 and 192.1 on 1600x1000.

Control: the ceiling back at 200 fails "leaves the outermost ring clear of the frame edge at every
scale and window shape".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:42:23 +02:00
SenrokaiandClaude Opus 5.5 869635bec1 Give a star no survey measured no luminosity, so its planets get no temperature from a stand-in
luminosityOf derived a luminosity from any magnitude, including the stand-in the ETL writes for
the 309 stars with neither a V nor a G. starSurfaceOf already refused it for the radius; the card,
the system view's planet appearances and the body pages did not. The 265 archive hosts among them
came out at a median 33 L☉: KMT-2016-BLG-1107L, a 0.087 M☉ star, at 36.8, and OGLE-2005-BLG-390L b,
published at about 50 K, read 388 K and a sub-Neptune. Their cards printed "Magnitude: Not
measured" beside a luminosity derived from that magnitude.

The guard now sits in luminosityOf, which every caller goes through, so the one in starSurfaceOf
is gone. The Sun keeps its 1 whatever band it is filed under. Measured on the shipped catalogue:
of the 275 planets on those 265 hosts, 268 had an equilibrium temperature and 0 now do; before
the archive stars were added they had no host, and so none either.

Controls: without the guard, "has none from a magnitude no survey measured, and gives its planets
no temperature from it" fails (with the radius test beside it, 2 of 777); without the Sun's
exemption, "is 1 for the Sun, whatever its magnitude is filed under" fails (1 of 777).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:39:45 +02:00
SenrokaiandClaude Opus 5.5 8c4f1c11c9 Build a body still waiting for its surface with a null map, so three stops warning on each one
Since de34fff paints derived surfaces after the system is built, every body without a photograph
was given map: undefined, and three's Material.setValues warns "parameter 'map' has value of
undefined" for each: eleven warnings every time the Sun's system was entered, one per exoplanet in
any other. The marker now starts with map: null, which three takes without a word and which
the deferred paint replaces as before. In the running app, entering the Sun (38 members) now logs
no console message at all.

Control: undefined again fails "builds a body still waiting for its surface without three warning
of an undefined map".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:35:27 +02:00
SenrokaiandClaude Opus 5.5 036af5f02d Test what the drawn solar system claims at far dates and on Saturn's ring
Three claims had no test that fails without them:

- Standish's rates for a, e and i. The frozen Horizons vectors run from 1950 to 2100, where
  dropping them moves a planet at most 0.036 degrees (Saturn in 2100), inside every ceiling; the
  clock runs to AD 3000, and the long span is what those rates are for. Two vectors from Horizons
  (DE441) for 3000-01-01 now join the table: the Earth-Moon barycentre, 0.005 degrees out (0.129
  without the rates), and Saturn's, 0.065 (0.412).
- A planet's orbit line turned each tick with its node and periapsis: only the Moon's and Pluto's
  were tested. Mars must stay on its own line 730 000 days before J2000; on a line left at J2000 it
  is 3.3 million km from it at AD 1.
- Saturn's ring lit and drawn from both faces, which dc20acc's title claims and the tests, reading
  only its geometry and picking through its front face, never checked.

Controls: the three rates dropped fails "puts earth within 0.02 degrees of Horizons on JD
2816787.5" (and Saturn's); the top-level line left unturned fails "turns a planet's drawn orbit
with its node"; an unlit front-face-only material fails "is lit, and seen from either face".

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-29 19:33:38 +02:00