4c8e4a0 added 3 277 hosts from the archive, 2 883 of them past 250 pc and 916 past a kiloparsec,
most in the Kepler field. Every host got a 12 px ring whatever its distance and a place in the
draw budget's first tier after the pinned stars, rules set when 1 of 1 379 hosts lay past 250 pc.
At boot the opening view held 3 332 rings against 1 290 before, 1 687 of them in its lower right
(x > 1000, y > 550 at 1600x1000) where there were 116, over the 250-350 pc grid labels; hosts 1-3
kpc away read as neighbours in a view whose range is 307 pc, and 629 stars past a kiloparsec were
drawn where there had been 3.
Rings and the host tier now take the hosts within SURVEY_EDGE_PC only. The far hosts still compete
for the budget by brightness, and search still enters them. Measured in the running app at
1600x1000: 1 853 rings in all, 1 698 in the opening view, 199 in its lower right; 31 stars past a
kiloparsec drawn; 1 767 hosts drawn. This reverses "a ring on every host" for the far ones: that
was the user's rule of 2026-09-17, when the only far host was one star, so it is flagged for them.
The scene test's fixture gains the lens's planet, 6.7 kpc out. The new test checks the ring count
and the host tier; the opening-view test now expects the lens out of that tier. Control: dropping
the distance condition fails the new test and that one (2 of 824).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
d1aa22e framed a giant so its disc took half the view's tighter half-extent, inside the ring its
neighbours are named on at 0.74 of it. It measured that at 1600x1000 only. The names hang a fixed
distance in from the ring, 74-78 px, so on a 390x844 phone the 0.24 of the half-side between disc
and ring is 47 px and the names land on the disc: Betelgeuse was drawn 98 px wide with HD 39374's
name 70 px from its centre, Antares with HD 148199's at 68 px.
The framing now takes the canvas's shorter side and keeps the disc inside the ring less 90 px,
at most half the half-extent as before, at least a tenth. Measured in the running app at 390x844
on arrival: Betelgeuse, Antares and Rigel drawn 54 px wide, the nearest names at 70, 68 and 127
px. At 1600x1000 nothing changes: Betelgeuse 250 px, its nearest name at 296. The ring's fraction
moves to system-framing.ts, beside the rule that depends on it, and the scene reads it there.
The review's other half, that the Readout sheet covers 44 % of the disc once opened on a phone, is
not changed: the dock opens with no panel below 640 px and folds it on any tap on the scene, so
the star arrives with nothing over it.
Control: giving the names no reach fails "keeps a giant's disc clear of its neighbours' names on
a phone" alone. The scene's passing of the canvas size has no unit test (the test canvas has no
size); the app measurement above covers it.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
23547de gave archive hosts measured in no colour a B-V read off the dwarf sequence at their st_teff,
and the card's Colour row says so, but the subtitle then estimated a type from that colour and
said "from colour". 30 of the 54 flagged stars read that way: PSR J1719-1438, a millisecond pulsar
whose only input is st_teff 4 500 K, read "Spectral type ~K5, from colour" beside "B-V 1.13, from
its temperature"; DP Leo ~B7, ZTF J1828+2308 ~B5, ZTF J1230-2655 ~A0.
The subtitle now ends ", from its temperature" for those 30. In the running app the pulsar's card
reads "Spectral type ~K5, from its temperature" above "B-V 1.13, from its temperature". The type
itself is still the dwarf the temperature matches, which a pulsar is not; this only stops it
naming a measurement that does not exist.
Control: ignoring the flag fails "says an estimate came from the temperature where the colour
was read off it" alone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Once the archive's 3 277 hosts became stars and 574 Gaia hosts took their names, "K2-18" listed
the star K2-18 and then K2-180 to K2-186, and no planet: "k2-18 b" and "k2-180" were both prefix
matches, and on a tie the ranking put every star before every exoplanet. Replaying each host's
name through the ranking over the published catalogue, 325 hosts had some of their own planets
pushed out of the eight rows shown (655 planet rows), against 75 before the archive stars.
A prefix match that ends where a word does now scores 3.5, between an exact match and a prefix
running on into the same word. The same replay gives 50 hosts and 62 rows. In the running app
"K2-18" lists K2-18, K2-18 b, K2-18 c, then K2-180 onward; "Kepler-186" lists the star and
Kepler-186 b to f before Kepler-1860; Kepler-22 b and WASP-12 b are back. "Proxima", "Io" and
"TRAPPIST-1" list as before.
Control: scoring the word-ending prefix level with any prefix fails "lists a host's own planets
ahead of the systems whose names run on from its own" alone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2242fe0 gave every star the Sun's photograph in grey, tinted at its temperature and limb-darkened
as 1 - 0.6(1 - mu), and nothing tested any of the three: with the coefficient at 0, the tint
dropped from the material, or the photograph replaced by the tint alone, all 817 tests passed. The
one colour test read scene.starTint, a uniform the scene sets whether or not the material uses it.
The new test enters Proxima and walks the disc material's colour node graph for the tint uniform,
the texture loaded from SUN_TEXTURE_PATH and the coefficient 0.6. Controls, each failing it alone
(1 of 820): the coefficient at 0; at -0.6, a limb brighter than the centre; the tint dropped; the
photograph replaced by the tint. A mutant that keeps the texture node in the graph but multiplies
it by nothing is not caught; the test checks the parts, not the arithmetic between them.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
95ffb00 said the field took "the same function and the same temperature the disc is drawn with".
It did for stars without planets, but a host's disc is drawn at the archive's st_teff
(starSurfaceOf), and the field read the host's temperature off its colour. Of the 4 485 hosts with
a temperature on the published catalogue, 1 755 were more than 0.1 in RGB from their own disc:
Kepler-186 at 3 096 K in the field and 3 788 K on its disc, HD 97048 at 6 825 and 10 000.
The scene now hands StarFieldRenderer each host's first published temperature among its planets,
the rule starSurfaceOf uses (publishedTemperaturesK, beside it), and the field tints that star at
it. Over the catalogue the hosts more than 0.1 off their disc go from 1 755 to 0. Measured in the
running app at 1600x1000, field tint against the disc's starTint after entering each: Kepler-186
(1, 0.620, 0.326) against (1, 0.619, 0.326), where the field was (1, 0.498, 0.174); Teegarden's
Star 0.001 apart; Proxima, HD 97048 and Sirius 0.
The field's test compared colorIndexToRgb with the same formula. The new scene test enters Proxima,
whose B-V 1.8 reads 3 070 K and whose disc is drawn at the archive's 2 900, and compares its field
colour with the disc's. Controls, each failing that test alone: the field ignoring the map it is
given, and the scene passing an empty one.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A non-giant with a spectral type but no colour took its temperature off the textbook colour
spectralTypeToColorIndex gives its type, read on Pecaut & Mamajek's table, and its bolometric
correction off the old textbook anchors. The table puts those colours elsewhere: M8's B-V 1.88
is M5-M5.5 there, 3 001 K where M8 V is 2 570, and the anchors give M8 -3.92 where the table has
-5.65. GJ 3655 (M8, 14.35 pc) was drawn at 0.035 solar radii, a third of Jupiter, where its
type's row gives 0.106 (Mamajek's M8 V: 0.114). Every O type came out B0's 31 400 K.
Both now read dwarfSequenceAtType, which already existed for the giants, and a G magnitude is
carried to V at the type's G-V too. On the published catalogue, of the 835 non-giant stars with
a band, a type and no colour, those more than 200 K off their type's row go from 21 to 0, those
with a radius more than 1.5 times off it from 7 to 1 and a luminosity from 10 to 1 (the one left,
Oph 11, is a G-band star). GJ 3849 (dM9) goes from 0.030 to 0.089 solar radii, GJ 3855 (M6.5)
from 0.040 to 0.087.
Two tests pinned the textbook path and now read the table: M5Ve with no colour is 3 060 K, not
3 106, and K5 tints as B-V 1.15, its row, not 1.105. An O8 star is 35 100 K, its row, not B0's.
Controls: reading the temperature through the textbook colour again fails "is drawn at its
type's row of the dwarf sequence" (with the three updated tests); reading the correction off the
anchors again fails that test alone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Every star but the Sun was a flat disc of one colour, and the Sun wore the texture pack's orange
photograph, lit by the same white light as every other star's planets.
Every star now shares one TSL material (starSurfaceMaterial in the scene): the Sun's map in grey,
times the colour of a blackbody at the star's temperature, times a linear limb-darkening law,
1 - 0.6 (1 - mu), the Sun's coefficient in the visible. The temperature is the one the radius
uses: the archive's st_teff for a host, else the dwarf sequence at its colour or type, else
the Sun's.
The colour comes from blackbodyColor (stellar.ts): Kim et al.'s cubic fit to the Planckian locus,
then CIE XYZ to linear sRGB, brightest channel 1. At D65 it gives 2 900 K (255, 180, 103), 5 800 K
(255, 241, 235) and 9 600 K (208, 219, 255), against (255, 182, 98), (255, 241, 231) and
(211, 221, 255) in Charity's integrated blackbody table. The tint is a uniform, so the shader is
built once and not per system.
The star's PointLight takes the same colour against the Sun's, since the planets' photographs
were taken in sunlight: the Sun's light stays white at pi, TRAPPIST-1's (2 566 K) is
(1, 0.44, 0.10) and Proxima's (2 900 K) (1, 0.52, 0.17), Sirius's (0.52, 0.67, 1). The intensity
stays pi. No halo comes back.
sun.jpg was 2048 by 1024 and 822 427 bytes for a disc that reaches 216 px across at the Sun's
closest approach on a 1080-line screen. It is now 1024 by 512 in grey, 31 306 bytes, which covers
the disc to a 1440-line screen. Its brightness varied by 56 % rms, which made every star a mottled
rock; it is rescaled to 14 % rms about the display's white, of the order of the Sun's granulation
contrast, the brighter half clipped as in a photograph exposed for the disc (6 % rms remains).
Measured on the dev server (1600 by 1000, the camera at its closest approach):
- the disc's brightness against the law, from r/R 0.52 to 0.97: Sun 0.970/0.841/0.763/0.657/0.560
against 0.927/0.829/0.755/0.645/0.554, ups And and Sirius the same to within 0.05;
- the disc's centre in sRGB: Sun (245, 233, 226), ups And (F8V, 6 157 K) (249, 239, 239),
Sirius (199, 209, 243);
- the first system entry of a fresh page, three runs each in alternating blocks against the
previous commit: Sol's longest task 90 ms before, 86 ms after, two tasks over 50 ms in every
run either way; Proxima Centauri's none over 50 ms after, one run of six with a 53 ms task
before. The long tasks on Sol's first entry predate this change.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The system view drew the Sun at its own radius and every other star at 0.45 of its innermost
orbit, capped at 0.2 AU: a size chosen so the star would not swallow its planets, not the star's.
Proxima Centauri was drawn at 2.8 solar radii, eighteen times its own, and every star without
planets at 43.
starSurfaceOf (body-view-model.ts) now gives each star a radius and a temperature. A planet host
takes the archive's st_rad and st_teff from its planets' rows: 4 439 hosts are drawn at a
measured radius, 22 at a derived one. Every other star's is derived: its temperature off Pecaut & Mamajek's dwarf
sequence at its colour (the same table the spectral estimate reads, or at the colour its type
implies where it has none), its luminosity from its absolute magnitude and the bolometric
correction luminositySolar already applies, and R = sqrt(L) / (T / 5772 K)^2. Against the
archive's own st_rad for the 1 447 catalogue hosts that have one, the derived radius is within
0.018 dex at the median, 0.071 dex at the 90th percentile, and within a factor of 1.5 for
97.1 %. Sirius comes out 1.79 solar radii (1.711 published, Liebert et al. 2005), Wolf 359 0.117,
Betelgeuse 584, the Sun exactly 1.
A star with no band has only the ETL's stand-in magnitude, and gets no derived radius: PSR
J1719-1438 came out 2.3 solar radii from it, wider than its planet's orbit. With the stars that
have neither a colour nor a type, that leaves 3 077 of 455 608 stars (274 of 4 735 hosts) with
no radius; they are drawn at the Sun's, and their card gives none.
The card says which it is: "Radius 0.141 solar radii" for a published one, "~0.10 solar radii,
from colour and brightness" for a derived one, two figures because colour does not give three.
A giant drawn at its size can be wider than its system, so systemFramingDistanceAu also makes
room for the star, and the controls' closest approach is now three of the star's radii where
that is more than the old 0.05 AU. 23 211 stars are drawn wider than 3.6 solar radii, which put
0.05 AU inside three of their radii, and a zoom would have carried the camera through the
surface of the largest. The Sun keeps 0.05 AU. starMarkerRadiusAu and the renderer's innermost
axis, which only it read, are gone.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
A star's luminosity was its absolute magnitude plus a bolometric correction read off its spectral
type, with its magnitude taken as V whatever band it was in. Gaia classifies none of its stars, so
all of its 379 000 got the Sun's correction, and their G was read as V: TRAPPIST-1 came out at a
seventh of its luminosity.
The dwarf sequence spectral.ts already reads types off (Pecaut & Mamajek 2013, table 5, online
version 2022.04.16) now carries its effective temperature, bolometric correction to V and Gaia
G-V columns, and dwarfSequenceAtColor interpolates them at a colour, in the colour's own system.
luminositySolar uses it wherever the star's colour is inside the table: the G magnitude is
carried to V, then corrected. Only without such a colour does it fall back to the spectral type,
as before.
Against the archive's own st_lum for the 1 449 hosts that are catalogue stars, the median error
goes from 0.038 to 0.022 dex and the 90th percentile from 0.292 to 0.115 dex; within a factor of
1.5, 84.5 % -> 93.8 %. For the 572 hosts Gaia describes: 90th percentile 0.332 -> 0.073 dex,
81.8 % -> 97.0 % within a factor of 1.5. Barnard's Star with no type now reads 0.0029 L_sun
against 0.0035 published, and TRAPPIST-1 7.3e-4 against 5.5e-4 (Agol et al. 2021).
Across the catalogue, 311 255 of 455 608 stars move by more than 10 % (median ratio 0.90: a
G-type star's G is 0.16 brighter than its V), and so do the hosts of 3 158 planets, whose
equilibrium temperatures follow as the fourth root.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The detail page and the system view's object card truncated the name and the line under it with
an ellipsis. For a designation, the part that went is the part that identifies it: the audit
measured "2MASS J21252752-8138278 b" at 288 px in a 256 px heading, shown as
"2MASS J21252752-81382…", and the eyebrow at 273 px, shown as "EXOPLANET · 2MASS J21252752-8138…".
Both lines now wrap (wrap-break-word) in both places. On the dev server the heading for that
planet is two lines, 45 px high, with its scroll width equal to its 256 px box, and the eyebrow
fits in 256 px.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
383 695 of the 455 608 stars read "Spectral type Unknown", every Gaia star among them, although
380 884 of them carry a colour. The card now gives those the type of the dwarf whose colour is
nearest, in the colour's own system, marked as an estimate: TRAPPIST-1, BP-RP 4.90, reads
"Spectral type ~M8, from colour", which is how it was classified (M8 V). A star with neither a
type nor a colour gets no subtitle rather than the literal "Unknown".
The colours are Pecaut & Mamajek's mean dwarf sequence (2013, ApJS 208, 9, table 5), as Mamajek
maintains it online (version 2022.04.16, which carries Gaia BP-RP), from B0 to M8.5. B-V cannot
tell O types apart (the whole sequence spans 0.03 of it), and BP-RP turns back past M8.5 and is
tabulated only from B9. A colour outside the table gets no estimate: 186 BP-RP and 41 B-V colours,
among them the blue Gaia DR3 5612323414549657984 at BP-RP -0.15.
380 657 stars get an estimate: F 97 840, G 144 327, K 105 984, M 29 142, A 3 272, B 92. Checked
against catalogued types:
- 19 433 HYG dwarfs with a B-V: 74.3 % within two subclasses, 95.5 % within five.
- 146 Gaia exoplanet hosts the archive types as dwarfs, from BP-RP: 88.4 % within two
subclasses, 98.6 % within five.
The estimate assumes a dwarf, so a giant reads later than it is (Pollux, K0 III at B-V 0.99,
reads K3). It also ignores reddening. The comment says both.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The readout named Hipparcos, Yale and Gliese while 378 775 of the 455 608 stars are described by
Gaia DR3, printed one "Magnitude" for G and V alike, and gave every distance to the parsec. The
band cannot be read off the star's source, which records whose position it has: 62 002 stars Gaia
places keep HYG's V and B-V, and the 575 hosts renamed after their planets are Gaia's, in G.
stars-meta.bin gains two byte columns, 14 to 16 bytes a star (6 378 512 to 7 289 728 bytes; gzip
-9 2 804 049 to 3 110 991). One holds the magnitude's band (V 76 555 stars, G 378 744, none 309,
whose magnitude is a stand-in), which colour the colour index is (B-V 75 203, BP-RP 376 703), and
whether the distance is Gaia's parallax. The other holds the distance's relative error as its
square root in 255ths: a step is 0.08 % of distance at 1 %, 0.35 % at 20 %, and 100 % is the top.
encode, decode, BYTES_PER_STAR_META and the build.ts round trip cover both; no workflow reads the
format.
Where the errors come from:
- Gaia rows keep the parallax_error their query already fetched: median 0.3 %, 90th percentile
1.2 %, at most 20 %, the query's own cut.
- A HYG star at Gaia's distance takes the cross-match's parallax_over_error, and a star merged
into a Gaia entry keeps that entry's error with its position.
- The 3 067 Hipparcos stars that keep their Hipparcos distance, Rigel, Deneb and Alnilam among
them, take e_plx from van Leeuwen's 2007 reduction: a new cached query of
public.hipparcos_newreduction on the ESA archive, whose 117 955 rows HYG's distances invert.
- The archive's stars take sy_disterr1/2 from pscomppars, in a query and cache file of their own
so the composite rows already cached were not refetched.
- 439 distances have no published error: 357 Gliese rows and 82 archive hosts.
Of the errors, 392 786 are 1 % or less and are not printed; 61 156 print as "117 ± 12 pc" to the
distance's own digits; 1 196 between 20 and 100 %, and 30 past it, print as the range the
parallax gives, since a symmetric error in parallax is a lopsided one in distance.
The star card (measured on the dev server) now reads, for example:
- Rigel: 265 ± 23 pc, V 0.18, B-V -0.03, source HYG.
- Deneb: 433 ± 60 pc.
- Alnilam: "476 pc to 833 pc" (Hipparcos 1.65 ± 0.45 mas).
- Gaia DR3 5612323414549657984: 111 ± 2 pc, G 4.63, BP-RP -0.15, source Gaia DR3.
- Proxima Centauri: 1.30 pc, V 11.01, source "HYG, Gaia DR3 distance".
- TRAPPIST-1: G 15.62, BP-RP 4.90, source Gaia DR3.
- Kepler-186: V 15.14, source NASA Exoplanet Archive.
The neighbourhood's subtitle reads "Gaia DR3 378,775 · HYG 73,556 · NASA Exoplanet Archive
3,277", counted by the catalogue describing each star.
build.ts validateStars now fails a catalogue with more than 1 000 stars without a band (309
today) or without a distance error (439). Dropping G from the Gaia rows gave 379 040 without a
band, and dropping their parallax_error gave 441 216 without an error; both runs failed.
Decoding the catalogue in Node took a median 29 ms before and 24 ms after (nine runs each, within
noise). In the app, five cold boots gave a 654-786 ms long task after the data landed and the
HUD at 1.83-2.07 s.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The off-screen rule for clicks was described in 3f0abf8 and in the pull request, but only its
comment was committed: pickAt still let the slop reach past the frame. The mutant that was said
to catch it matched nothing, and an unrelated flaky test failed instead. The frame test is now in
pickAt, before the slop, and its test fails without it (star at NDC 1.01, click at 0.995).
Venus, Uranus and Pluto turned forwards: Horizons states a retrograde spin twice, by a negative
rate and by an obliquity over 90 degrees, and both were applied. The period's sign is now used
only when no obliquity is known. Measured on the live markers, spin axis against orbit normal is
cos(obliquity) for each: Venus -0.999, Uranus -0.135, Pluto -0.494, Earth 0.917.
Moons listed as rates rather than "Synchronous" drifted about 5 degrees an orbit and Titan did not
turn: every moon is now locked at its Kepler period. Pluto's obliquity comes from IAU WGCCRE 2015,
Horizons gives none.
Also:
- the star's light is white at pi, not a warm 2.2 that left the photographs dim;
- procedural textures are 128x64, not 512x256 that froze the main thread ~60 ms a body;
- Io, Pluto, Titan and Deimos lose their "maps", which were disc photographs with black sky;
- an exoplanet with only a mass gets a radius from it (M^0.55, capped at Jupiter), not Earth's;
- the clock knows when it has left the present even once back at real time, so the date and
"Back to now" stay up.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Every body in the system view was an unlit sphere wearing a 32 by 16 pixel
procedural texture — the size chosen when a marker was a few pixels across and
what survived was its average colour. The thirteen real photographs in
`src/assets/textures/bodies/` were used only by the detail page. So Mars was a
pale grey ball with invented polar caps while its own NASA mosaic sat unread in
the repository, and nothing had a day side or a night side.
Each marker now takes its own photograph where one exists, at the size the
detail page uses, and the derived texture only where none does — the five moons
no probe mapped, and every exoplanet, none of which has ever been imaged. The
material is lit, and the light is a point at the star, so each world shows the
terminator where it really falls.
The light does not fall off with distance. Under the inverse square that real
light obeys, Neptune receives a thousandth of what Mercury does and reads as
black; the map is a set of worlds to look at rather than a light meter, so each
is lit as a photograph of it would be. That is the same concession the pixel
floor makes for size, and it is only about brightness: the *direction* is real.
Spheres are 32 by 24 rather than 16 by 12, since at true scale a body is drawn
anywhere from a pixel to the whole frame and the old silhouette was visibly
faceted at the near end.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The orbits and the rotations are both functions of a date, and the only date the
map ever asked for was this instant. So a view built on propagated ephemerides
showed a still picture: Earth turns 15 degrees an hour and takes a year to go
round, and a reader watching for a minute saw nothing move at all.
`TimeStore` is that date, at a rate the reader sets: real time, an hour a
second, a day a second, a month a second. It is read once a frame rather than
held in a signal — it changes continuously, and a signal changing sixty times a
second would ask the whole HUD to re-render for a number nothing is watching.
Changing the rate re-anchors rather than rewinding, so speeding up and slowing
down never jumps the sky, and "Back to now" returns to the world's own time.
Measured in the app, three seconds of watching in the Sun's system:
| rate | sky elapsed | Earth turned | Jupiter moved |
|---|---|---|---|
| real time | 0 | 0 | 0 |
| 1 h/s | 3.0 h | 45.12 deg | 0.0009 AU |
| 1 d/s | 3.0 d | (three full turns) | 0.0222 AU |
45.12 degrees in three hours is 15.04 an hour, which is Earth's own sidereal
rate, and Jupiter's 0.0222 AU in three days is its own orbital speed.
The rates are radio buttons, not toggles: they are one of four, and the native
control carries that to a screen reader and to the arrow keys with no script.
The date joins the strip only while the clock is running faster than the world,
since at real time it is today's, which the reader's machine already says.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The view had one rotation in it — the planet on the detail page, at 0.08 rad/s,
a number with no source. Nothing in the system view turned at all.
The data was already on disk: every cached Horizons page carries how its body
spins, in one of five forms. The rate in radians per second is preferred where
it appears, because it is signed — that is how Venus and Uranus are known to
turn backwards — then a period in hours or days, then the `9h 55m 29.711 s`
the giant planets use, and finally the word every major moon here carries
instead of a number: Synchronous. A tidally locked moon's day is its orbit, so
Kepler supplies it from the elements already parsed and the parent it goes
round.
Seventeen of the eighteen bodies come out within 1% of their published period —
Earth 23.934 h, Jupiter 9.925 h, Venus -5832.5 h, Io 42.5 h, Callisto 400.5 h.
Titan is the exception: its page states no period at all, so it is left still
rather than turned at an invented rate.
The axis is the orbit normal tilted by the obliquity about the orbit's
ascending node, which is where an obliquity is measured from and the only line
in the orbit the elements name. The phase at the epoch is published for none of
these bodies, so the face turned toward the camera is not a claim; the rate and
the direction are.
At true rates nothing is visible moving — Earth turns 15 degrees an hour. A
clock the reader can run faster is the next piece, and the audit asks for it
anyway.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
Three changes to what the system view claims, all of them the same claim: that
the sizes on screen mean something.
**The halo is gone.** It was a sprite sized against the arrival frame — 1.12 AU
for the Sun — so it stayed that wide as the camera closed in and ended up a flat
gradient filling the screen, over the photograph it was meant to dress. It
existed to keep the star visible at a framing that holds the whole system, which
is now handled in pixels instead.
**Bodies are drawn at their own radius.** The old marker size was exaggerated
and scaled to the system span, and clamped: Jupiter and Ganymede both ran past
the ceiling and were drawn at one radius, so every moon orbited inside its
planet, and Phobos and Triton sat entirely within Mars and Neptune. True scale
needs no rule against that — physics already puts a moon outside the planet it
orbits. What it costs is visibility at the arrival framing, where every body is
sub-pixel, so the scene floors each marker at 3 px on screen and holds a moon to
half its planet's drawn size. Measured in the Sun's system: at arrival, planets
3 px and moons 1.5 px, against 3 px for everything before; at Jupiter, the
planet 10.8 px at scale 1 with the Galilean moons on their orbits outside it.
The Sun is drawn at its own radius too. Every other star keeps a size derived
from its innermost orbit, because no stellar radius reaches the app — Gaia's
`radius_gspphot` is the obvious next fetch.
**A click cannot enter a system that is not on screen.** The picker tested depth
but not the frame, and a star's hit area is its drawn size plus a slop, so a
click in the last pixels of the view could fly into a system outside it, with
nothing on screen to explain where it had gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
Both sides added a test beside the other in the dock's spec: the panel's own
departure guard here, the give-up wording on main. Both kept, and the offer test
carries the `least` the route answer now has.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
The span went to `distanceRings` as the target's straight-line distance from the
Sun, but a ring of radius r passes within |r - p| of the view's centre, where p
is how far out that centre is *along* the galactic plane. For a target above the
plane the two differ by its height, so the band was centred on a radius no ring
has — and `ringLabels` picks its bearing by comparing its own in-plane distance
against the innermost ring, a comparison the new first ring quietly broke.
Two comments and a constant, from the same review. A frame short of the survey
edge gets its callout only when its last ring overshoots it: 245 pc does, 235 pc
does not, which is now a test rather than a sentence. The ring count can reach
16, not 14, now that the span need not start at the Sun. And a ring label was
measured as 135 px of star name when "50 pc" is a third of that, which rejected
rungs a hand's breadth clear of the name: RING_LABEL_REACH_NDC, 0.23, is the
widest of them — "1.5 kpc" with "Survey edge" under it.
Three mutants, three caught. Measured again in the app: unchanged for a star in
the plane (4 labels at 20 pc above it, 7 at 2 pc), and the rings now follow the
plane for one 195 pc above it rather than ringing a place the grid does not
reach.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
`canPlot()` guarded the Plot button and not `raiseTo`, which is the other way
into `plot()`. So with a departure typed but never chosen, clicking "1.8 pc
would reach." moved the range control and plotted nothing: the panel then read
"No route at this range. 1.8 pc would reach." beside a control already set to
1.8. The offer carries the same `disabled` as the button, since it is the same
request by another route.
And the departure guard is trimmed, as the scene trims the same text before
offering matches for it: one space in the field left it looking empty, with no
suggestions to pick from, and Plot dead for no reason on screen.
Measured in the app, from inside Barnard's Star with Sirius as the destination:
offer enabled with the field empty, disabled once "Sol" is typed and never
chosen — a forced click then moves nothing — and enabled again when the field is
cleared, where it raises the range to 2.40 pc and plots 7 jumps.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
The rings are centred on the Sun and the frame need not be. Sizing their step
from how far the frame reaches — 210 pc for a star at 190 with the camera 20 pc
back — gives 20 pc rings at 180 and 200, both outside a frame 19 pc deep, so a
view away from the Sun still had no ring on it and no ladder of labels either.
`distanceRings` now takes the span the frame covers rather than its far edge,
and the step is a fifth of that: 5 pc rings from 165 to 210 for the same view.
Measured in the app, centred on a star 187 pc out in the galactic plane: 4 ring
labels drawn 20 pc above the plane and 7 from 2 pc, against 1 and none before.
The clearance was a radius around the anchor, and a label is a line of text
hanging 135 px to one side of its anchor: at 0.065 NDC apart, past the radius,
"50 pc" printed inside "Alpha Centauri". It is now tested against the span the
name occupies, on the side it hangs, with the radius kept for the pair whose
text runs the other way.
Also from the review: the ladder in the clearance test was built at exactly the
constant it tests, so 1057 of 2000 camera poses would have decided it by float
round-trip error — the rungs now sit 0.02 either side of the rule. And two
comments that were wrong: a frame one step short of the survey edge does get its
callout, and CSS2DRenderer hides a label behind the camera rather than drawing
it at the page edge.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
The panel printed "No route at this range." beside the range it was offering —
which is the sentence this branch exists to stop it printing. It was gated on
there being no offer, and a search that gives up usually has one: Sol to
HD 120147 at 4.5 pc spends the budget, offers 4.83 pc, and says there is no
route where a 71-jump route exists. The wording now follows the search at the
range that was asked for, and nothing else.
That needs the two give-ups kept apart, so `least` travels beside `gaveUp` to
the panel: one says the asked range was not searched out, the other that the
search for a range that would work was. HIP 69445 at 3 pc — asked-range search
exhaustive in 44 ms, ceiling probe out of budget — used to read "Too many stars
to search at this range." and now reads "No route at this range.", with nothing
claimed after it.
Two more from the same review. The budget flag was read off the settled count,
so a search that proved a dead end with the last star it was allowed reported a
give-up; it now records why the loop stopped. And the bisection's cap could fire
before a single probe had narrowed anything, leaving the ceiling route's own
longest hop as the answer: star 1000115173 at 3 pc was told to go to 8.00 pc,
the control's maximum, for a crossing that works at 6. It now offers 6.93.
Measured in the app, all three: "Too many stars to search at this range.
4.90 pc would reach.", "No route at this range." alone, and 7.00 pc in place of
8.00. The duplicated dead-end test now asks the question it was named for —
exactly the budget's worth of stars reaching each other and none of them the
destination — and each fix kills its own mutant.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
From the review of #24. Two defects, both in a real browser.
The panel keeps its entries across a trip to another tab, but still replayed the acquire wipe on
the way back, and for the 380 ms that runs, its clip path swallows clicks: type "Siri", leave for
Readout, come back and click the Sirius suggestion, and the click lands on the star field behind
it — measured, the element under the pointer is the canvas, and the field stays "Siri". The wipe is
gone from this one panel: it is not acquiring anything it did not already have.
The departure field fell back to the star the view is in whenever nothing had been chosen, text in
the field or not. So a field reading "Sol" that was never resolved plotted from Barnard's Star:
"1 Barnard's Star, 2 Sol, 3 Sirius", the panel naming one departure and the route leaving from
another. Text nobody chose is no longer a departure, and the button waits until it is one or the
field is empty again.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
From the review of #19. The rings are distances from the Sun, but their step was taken from
`effectiveDistance`, which under the plan view means the extent of the frame rather than how far
the camera is from the Sun. Centred on a star 200 pc out and flipped to 2D, the grid became rings
of 2 to 20 pc: not one of them on screen. The step now comes from where the view is centred plus
how far the camera is orbiting it, which is the same distance under either projection.
The set was also rebuilt while the grid was hidden, and every rebuild disposes the rings and
builds every vertex again; it now happens only while the grid is drawn.
The ring labels went straight to the overlay: never culled to the frame, and free to land on a
star's name. They now have to be on screen and clear of the names already placed, by half the
separation two names keep — they are a ladder up one ray a twentieth of the screen apart, and
holding them apart from each other would take "Survey edge" off the map.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
The route search stops after MAX_VISITED stars and returned null, which everything downstream read
as "the catalogue holds no chain". On the real catalogue that was wrong for real questions: Sol to
HD 120147 (136 pc) at 5 pc is 50 jumps, and the panel said there was no route. The budget also sat
under what the shipped catalogue needs, so it is now 40 000 rather than 20 000: both that route and
a star at 170 pc are found, and Sol to HD 2626 at 6 pc, which used to be refused after 4.7 s, plots
56 jumps in about 2 s.
A search now reports whether it gave up. The range search no longer counts a give-up as proof that
nothing routes below it — that is what reported ranges up to 29% too wide — and it stops after two
of them, since those are the probes that cost the most and settle the least: for HD 2626 at 3 pc it
offers 5.92 pc in about 4 s, against 6.13 pc in 4.7 s. At the panel's widest range the refused route
and the range search are the same question, so it is asked once. Where nothing can be said, the
panel says "Too many stars to search at this range." rather than claiming there is no route.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
- The budget counted CSS pixels; lines are drawn in device pixels, so a screen scaled to 150% or
200% drew 1.5-2x the calibrated line. It now counts the canvas's drawn pixels.
- A graph was re-asked only when the drawn stars changed, so with a star budget covering the whole
catalogue, or a resize, its budget and centre stayed wherever the layer was turned on. A view that
chose its stars again now asks, and a graph is rebuilt when the stars, the range or the budget
changed (the budget by more than half the margin, or its centre by more than 5 pc).
- From inside a system the budget was worked out in astronomical units about the system's origin.
Graphs are now asked for in parsec space only; the flight back out asks.
- Comparing budgets let a request re-asked with a slightly different one supersede its twin, and the
twin's rejection cleared the state of the request that replaced it. A rejection now clears it only
for the latest request.
- The worker sorted every link to keep a few thousand, 2.2x an unbudgeted build. It now bands links
by distance, keeps every band before the one the budget runs out in, and sorts only that one:
142-168 ms on the real catalogue against 233-388 ms, 103 ms unbudgeted, returning early when all fit.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
With the drawn set following the view, the layer at 8 pc cost the integrated Radeon 503 ms a frame
at 30 pc from the Sun. Measured, the cost follows the length of line on screen (about 10 ms per
million pixels near the Sun), not the number of links: 100 000 links were 12 ms at the opening
view, 25 000 were 61 ms at 30 pc. So the budget is a length: a million pixels, turned into parsecs
at the depth the view is centred on, spent on the links nearest that centre by their nearer end.
Orbiting with links at 8 pc on the iGPU: 12-18 ms p50 at every pose measured, no long tasks.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
- Flights: the drawn stars were checked once a label pass, and a flight outruns that. Leaving a
system jumps the camera to face another way, then zooms out forty-fold in a second: 74-83% of
the stars that belong on screen were missing on the first frames back in parsec space, 33-50%
before each re-choice on the way out. While the rig animates, the check now runs every frame.
Probe on real flights (Gl 806, Barnard's Star, out): 0.90-1.00 of a fresh choice drawn on
screen in flight, 1.00 on the frame of the jump; frame p95 12.2 ms, no long tasks. Choosing for
the whole sky during flights was tried first and measured worse (0.15-0.18).
- Portrait frames: the turn and pan limits use the narrower half-extent, not the height.
- Links: a new drawn set arms the rebuild timer only when none is pending, so a continuous orbit
gets a graph at most every 250 ms instead of never; an unchanged set asks for nothing.
- The centre-move test lets the first pass happen before moving the centre.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
SenrokaiandClaude Opus 5.5