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>
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>
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>
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 README listed the four columns stars-meta.bin had before a81dd49 added the photometry byte
(magnitude band, colour system, whether the distance is Gaia's) and the distance's relative
error.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The derived equilibrium temperature balanced starlight alone. For the widest orbits that is less
than the 2.7 K every body in space is held at by the cosmic microwave background. The planet 7 493
AU from 2MASS J21252752-8138278 read "Equilibrium temp. 1 K", and the one 19 000 AU out from UCAC4
328-061594 would have read 0 K.
equilibriumTemperatureK now adds the background as a second source in the same balance, T^4 =
T_star^4 + (2.7255 K)^4 (Fixsen 2009). Inside a few hundred AU of any star it changes nothing that
shows: Earth, Mars, Jupiter and Neptune reproduce their published values as before. Across the
6 354 exoplanets, the rounded temperature changes for 11, all on orbits of 350 AU or more. Ten go
from 0, 1 or 2 K to 3 K, from VHS J125601.92-125723.9 b at 350 AU to UCAC4 328-061594 b at 19 000
AU, and 2MASS J22501512+2325342 b at 518 AU goes from 4 to 5 K. On the dev server, the detail
pages of the 7 493 AU planet and of GJ 900 b read "Equilibrium temp. 3 K".
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>
2 127 stars, Sirius among them, read "Spectral type A0m...", in search rows, route options and
the star card. The mark is Hipparcos's own: every one of the 3 803 HYG rows ending in it has a HIP
number, and the catalogue ends a classification it does not print in full with it. The app
truncated nothing, but the text reads as if it had.
fetchStars now trims a trailing "..." from HYG's spectral types. The dictionary in
stars-index.json goes from 3 056 distinct types to 2 883, and from 598 dotted ones to none. The
names, sources and source indices are unchanged, and so is every other column of stars-meta.bin
bar the type indices. gzip -9 of the index goes from 4 015 865 to 4 015 205 bytes.
build.ts validateStars now fails a catalogue with any type ending in "...". Run with the trim
removed, the ETL failed on 2 127 such types. Two ETL runs from cache wrote identical
stars-meta.bin and stars-index.json.
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>
After matching, 4 237 planets still had no star: their hosts are too faint for either Gaia
query (fainter than G 12 past 50 pc) or too far (past 250 pc), Kepler-186 at 177.6 pc among
them. fetchExoplanets now adds one star per such host from the archive's own figures, 3 277
of them, whenever the archive gives a position and a distance:
- position carried back from J2016, where the archive publishes it (741 of the 746 matched
hosts moving over 100 mas/yr sit nearer their star carried back, a median 0.11" against 3.47"
as published), and placed at sy_dist;
- magnitude in V (2 999 hosts), else Gaia G (13), the band the catalogue's Gaia stars are
already in; 265 have neither, 128 KMT, 95 OGLE and 32 MOA microlensing hosts at a median
6.2 kpc among them, and take the ETL's faint stand-in of 15;
- colour as B-V from the archive's B and V, else from st_teff through a new
temperatureToColorIndex (Ballesteros 2012, inverted; the Sun's 5 772 K gives 0.65), else
left to st_spectype;
- ids from 1 070 000 000, past Gaia's two ranges and under the 2^30 validateStars enforces;
source "exoplanet-archive".
Hosts past 250 pc are included: 399 of the 3 277 are within 250 pc, 1 962 between 250 pc and
1 kpc, 916 beyond. The drawn budget still chooses what is drawn (70 000 of 455 608).
Planets with a star: 2 090 -> 6 327 of 6 354. The other 27 have no distance in either table
(Luhman 16 A, mu2 Sco, PSR B1620-26 among them). Systems in the Solar Neighbourhood readout:
1 450 -> 4 736. validateExoplanets now refuses a catalogue where fewer than 99.5 % of planets
have a host (measured 99.58 %); dropping the added stars fails it at 2 090, and dropping the
composite fill at 6 227. No added star sits within an arcsecond of a catalogue star
(validateMerge's twins stay at 23); 5 of the 399 within 250 pc have one within a minute of arc,
VHS J125601.92-125723.9 (archive 12.7 pc) 5.8" from a Gaia entry at 21.2 pc the likeliest
duplicate.
In the app, searching TRAPPIST-1 or Kepler-186 and picking the star enters a system with its
seven and five planets drawn. gzip -9: stars.bin 5 030 741 -> 5 067 864 B, stars-meta.bin 2 784 614 -> 2 804 064,
stars-index.json 4 003 584 -> 4 015 882, exoplanets.json 342 467 -> 446 532 (host parameters,
both commits).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The archive's default-parameter rows leave sy_dist blank for 100 planets, TRAPPIST-1's seven
among them, so the matcher could not place a host the catalogue had drawn since the Gaia
nearby query (Gaia DR3 2635476908753563008, 12.47 pc). fetchExoplanets now also reads the
Planetary Systems Composite table (pscomppars) and fills a default row's blank host cells from
it. Only host columns: a composite row takes each column from its own reference, so orbits
still come from the default row alone, one fit per planet. Where both tables give a distance or
a position they agree on all 6 225 and 6 352 rows.
Three hosts the catalogue holds by name failed the distance ratio test because the archive's
sy_dist, from TICv8, contradicts its own parallax: Lalande 21185 (GJ 411) 5.68 pc against
392 mas, Luyten's Star (GJ 273) 5.92 against 263 mas, Struve 2398 B (Gl 725 B) 6.84 against
285 mas. resolveHostStarId now takes the archive's parallax (sy_plx) as a second distance the
ratio test accepts. It is a second chance, not a replacement: 47 of 5 959 systems disagree past
the tolerance, and for faint far hosts the inverse parallax is the worse figure (K2-238: 538 pc
by sy_dist, 6 779 by parallax).
Planets on a catalogue star: 2 071 -> 2 090 of 6 354. The 19 gained are TRAPPIST-1 (7),
GJ 273 (2), GJ 411 (2), Gl 725 B, HD 62509 (Pollux), K2-65, TOI-2267 A and B, and two
brown-dwarf hosts, 2MASS J02192210-3925225 and DENIS-P J082303.1-491201. No planet lost or
changed its host.
A matched host whose catalogue name is a bare Gaia designation now takes the archive's host
name, so search finds TRAPPIST-1, Teegarden's Star, TOI-700, LP 791-18 and K2-18: 575 stars
renamed. validateExoplanets refuses a host that is still only a designation, and the star
assets are rewritten after the exoplanets for that reason; stars.bin and stars-meta.bin are
unchanged. TOI-2267 A and B both land on one Gaia entry, which takes the name TOI-2267 A.
Each planet also carries its host's radius, effective temperature and luminosity (10^st_lum),
and a mass for 6 344 planets instead of 5 474, from the default row where it gives one and the
composite table otherwise, for the star-physics step.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
OpenNGC keeps the objects no NGC or IC number covers in a second file, addendum.csv, with the
same 32 semicolon-separated columns as NGC.csv. The ETL only ever fetched NGC.csv, so the
brightest deep-sky object in the sky, the Large Magellanic Cloud (V 0.29), was missing while
the Small one was drawn, and so were the Pleiades (M45), the Hyades, the Horsehead and the
Coalsack. fetchDeepSky now fetches the addendum beside NGC.csv, caches it as
openngc-addendum.csv, and runs its rows through the same loop.
Of its 64 rows, 27 pass the existing filters: all 22 named or Messier rows except M40, which
OpenNGC types as a double star, and M102, typed as a duplicate of M101; plus seven anonymous
open clusters brighter than V 9 (H05, H20, H21, Mel071, Mel101, Mel105, MWSC3171). deepsky.json
goes from 463 to 490 objects (galaxies 73 -> 85, clusters 294 -> 306, nebulae 96 -> 99), with
no existing record changed. Messier coverage goes from 106 to 107 of 110. 340 of the 490 have
a distance: the Pleiades 135.8 pc and the Coma Star Cluster 85.9 pc from their parallaxes;
the Hyades and the Local Group dwarfs honestly have none.
validateDeepSky now requires the Andromeda Galaxy and the Small Magellanic Cloud from NGC.csv,
the Large Magellanic Cloud and the Pleiades from the addendum, and at least 107 Messier
objects. Both checks were run against the real catalogue with the addendum removed: the ETL
fails on "Deep-sky object ESO056-115 is missing", and with the required list emptied, on
"Only 106 Messier objects were produced".
In the app, on the dev server: 490 sprites. The Pleiades sprite lies 0.00182 deg from Alcyone
(0.00183 deg from the published coordinates); the LMC 18.4209 deg from Canopus and 26.8215 deg
from Achernar (18.4209 and 26.8215 published); the Hyades 2.2591 deg from Aldebaran (2.2591).
The twelve labelled deep-sky objects now open with the Large Magellanic Cloud and the
Pleiades and include Brocchi's Cluster, in place of h Persei, chi Persei and NGC 2516.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Gaia's G < 12 cut took a quarter of what lies within 10 pc: the red,
brown and white dwarfs most of the neighbourhood is made of, which the
map only had where Gliese happened to list them. Teegarden's Star was
missing, and with it its three planets' host.
A second query fetches the complement out to 50 pc: G >= 12 or no G,
parallax > 20 mas, with pmra/pmdec so the J2016 -> J2000 propagation
applies. The quality filter was chosen by counting. Parallax over error
> 5 keeps 39 751 of the 39 764 sources that pass the floor, but the Gaia
Catalogue of Nearby Stars (GCNS; Gaia Collaboration, Smart et al. 2021)
rejects 11 752 of them as spurious: median G 20.2, astrometric excess
noise 5.4 mas against 0.15 for the ones it keeps, 6 933 toward the
Galactic centre. So the query joins the GCNS main table (EDR3 astrometry
and source ids, which DR3 carries unchanged) and keeps 28 012 rows; the
error cut stays and costs no GCNS source, brown dwarfs included. The
query has its own row-count floor (28 012) and the row-limit cap, and is
ordered by (phot_g_mean_mag, source_id); a second ETL run reproduced
stars.bin, stars-meta.bin and stars-index.json byte for byte. Its ids
start at 1 050 000 000, clear of the main query's and under 2^30, which
V8 keeps unboxed: numbered from 2 000 000 000 they made the app's boot
task 230 ms longer (medians of five interleaved runs, 1.41 s against
1.18). validateStars now refuses an id outside 0 to 2^30.
The Gliese entries these stars duplicate were not folded: HYG carries
them with positions off by up to a minute of arc and photometric
distances, so they missed the 15" tolerance or failed the distance test.
Their proper motions, which Gliese measured well, give them away:
isSameStar now takes two entries moving within 20 % of each other as one
star up to 60" apart, whatever their distances, brightness still
permitting. Of the 602 Gliese-only rows left without a counterpart, 253
have such a Gaia entry; with every entry shifted a quarter degree, none
does. fetchStars passes HYG's motions only for rows without Hipparcos
astrometry: given them too, 15 Hipparcos stars took a co-moving
companion's Gaia entry and the cross-catalogue pairs under an arcsecond
went from 23 to 35. Of HYG's 1 200 stars fainter than V 12 within 25 pc,
1 024 now sit on a Gaia position (325 before); of the 176 left alone, 43
still have a Gaia entry 3-60" away (218 without the motion rule), some of
them real companions.
Measured on the rebuilt catalogue, against the GCNS (sources with
parallax > 100, 40 and 20 mas):
within 10 pc 336 -> 372 (GCNS 312; the map adds 60 HYG-only stars)
within 25 pc 3 652 -> 5 560 (GCNS 5 111)
within 50 pc 13 702 -> 40 916 (GCNS 40 231)
452 331 stars (+27 214). Proxima, Barnard's Star, Wolf 359, Rigel, Deneb
and Alnilam are all present by name; Teegarden's Star is Gaia DR3
35227046884571776 at 3.83 pc and hosts its three planets. Luhman 16 is
not in Gaia DR3 with a parallax (5353626573555863424 has a two-parameter
solution) and stays absent. 94 more exoplanets find a host (2 071), none
changes host. TRAPPIST-1 is now drawn (Gaia DR3 2635476908753563008,
12.47 pc) but its planets are not yet matched to it.
Merge gate, ceilings unchanged: HYG rows without a Gaia counterpart
12 352 -> 11 554 (ceiling 15 000; 10 886 before the naked-eye stars),
cross-catalogue pairs under an arcsecond 23 -> 23 (ceiling 100). The
gate's comment now accounts for the survivors by magnitude.
gzip -9 sizes against the catalogue before both changes: stars.bin
4 711 922 -> 5 030 741 B, stars-meta.bin 2 576 213 -> 2 784 614 B,
stars-index.json 3 724 855 -> 4 003 584 B (+806 KB, 7.3 %). Boot on the
dev server, five interleaved cold runs: the task that indexes the
catalogue after the data lands, median 1 072 -> 1 182 ms; HUD shown,
median 2 622 -> 2 716 ms. This machine measured 0.82-1.30 s for the
same baseline task today, above audit #25's 627-843 ms. The drawn-star
budget is unchanged.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The 250 pc cutoff took 1 543 of HYG's 8 920 stars of V 6.5 or brighter:
1 339 that both surveys put past it and 204 HYG has no distance for. Five
of the fifty brightest stars in the sky were gone (Rigel, Deneb, Alnilam,
gamma-2 Vel, Wezen), and Naos, Sadr, Aludra and Arneb with them, while
11th-magnitude Gaia stars at the same distance were drawn. The cutoff
bounds a download, not what the sky shows.
placementDistancePc now keeps a star of V 6.5 or brighter at any distance,
at the better of its two distances as before: Gaia's where the archive's
Hipparcos cross-match has a usable parallax, Hipparcos's otherwise. Gaia
saturates on the brightest, so Rigel (264.6 pc), Deneb (432.9), Alnilam
(606.1), Wezen (492.6), Naos, Sadr, Aludra and Arneb sit at their
Hipparcos distance. 1 502 HYG rows come back, 165 of the 206 without a
Hipparcos distance among them because Gaia measured them; 36 fold into a
Gaia entry. 41 naked-eye stars stay out because neither survey gives them
a distance: beta Phe, Polis, Mu Cep, Rho Cas, Eta Car, Alp Cam, Phi Cas,
Chi Aur, Psi-1 Aur, theta-1 Ori, Omi-1 Cen, 66 Ori, 16 Sgr, 10 Sge and 27
HD stars.
Measured on the rebuilt catalogue: 425 117 stars (+1 466), 8 301 of them
past 250 pc (+1 466), the same 336 within 10 pc and 3 652 within 25 pc.
Merge gate: 12 352 HYG rows without a Gaia counterpart (was 10 886; the
ceiling of 15 000 is unchanged, and its comment now counts the naked-eye
stars among the survivors) and the same 23 cross-catalogue pairs under an
arcsecond. Five more exoplanets find their host: HD 81817 b and c,
HD 158996 b, HD 208527 b, HD 220074 b. gzip -9 sizes: stars.bin
4 711 922 -> 4 728 315 B, stars-meta.bin 2 576 213 -> 2 587 977 B,
stars-index.json 3 724 855 -> 3 731 763 B.
The brief behind this also asked to cut once on the best distance, which
would drop the 6 835 stars Hipparcos puts inside 250 pc and Gaia outside.
Those already sit at Gaia's distance (4eb61ff), so nothing is misplaced,
and they stay.
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
The fixture built for "exactly MAX_VISITED stars reachable" was 338 short: its
random cloud leaves clumps the departure never reaches (the LCG gives 12 212
distinct positions for 39 999 stars), so the search settled 39 662 and the
pre-fix code answered `gaveUp: false` too. The test could not fail on the code
it was written to pin — and the mutant that seemed to prove otherwise was
failing to compile, not failing the test. It is now a line of 40 000 a parsec
apart with the island off the line: settled 40 000 exactly, 115 ms, and the
pre-fix code does report a give-up. Both mutants now compile and are caught.
The give-up cap also has to hold while the bisection has earned nothing: the
exception added for that case had no bound at all, so a search could spend the
resolution's own eight full-budget probes — about 17 s of "Plotting…" — where
two used to cost 4 s. Bounded at five. On the repo's crowded-knot fixture:
1.9 s for the unearned ceiling figure with the old cap, 7.2 s for a range the
bisection earned, and five probes is where that lands.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
Gating it on `jobsQuery` switched it off for every override that *widens* the
query — which is the only way to fill `select top N` at all. `ETL_GAIA_MAGNITUDE_LIMIT=14`
asks for 500 000 rows, the sky holds more, and the answer is the limit rather
than the filters: exactly what the tripwire is for, and it no longer fired. It
now reads the row limit itself, so only a deliberately smaller slice is silent.
Measured with a synthetic answer of exactly 500 000 rows in the cache, under the
key the widened query hashes to: refused. With the `jobsQuery` gate back, the
same run keeps 500 000 Gaia stars and goes on to publish them.
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
Three things this got wrong. The direction: truncating Gaia leaves the HYG rows
whose counterpart it dropped without one, so survivors rise — 10 886 today,
12 711 at half the rows, 16 258 at a third — which the comment claimed was the
other way, and which decides whether the 15 000 ceiling can be leaned on at all
(it catches a truncation past about two thirds, and nothing shallower).
The throw: `fetchStars` catches everything a source throws and skips it, so a
truncated CSV was reported as "the archive was unreachable" one step after
`writeStarAssets` had already overwritten the published catalogue. Marked with
`GaiaAnswerError` and rethrown there, so an answer that cannot be worked with
fails the run where it happened. Measured end to end in a throwaway working
directory, 300 000 rows in the cache: fails, names the cache file to delete,
assets untouched. With the rethrow taken back out again: assets written, then
"the archive was unreachable".
The row limit: `rows.length >= ROW_LIMIT` is true for every reduced
ETL_GAIA_ROW_LIMIT, so the tripwire fired on exactly the deliberate slice the
override exists for — and told the operator to raise it. Gated on the same flag
as its neighbour. `ETL_GAIA_ROW_LIMIT=20000` now runs through; without the gate
it dies on the limit it was given.
Also: the row floor names the one cache file it is about rather than a glob that
takes the Hipparcos cross-match with it, and says an edited query is a third
reason it can fire — DEFAULT_QUERY_ROWS now sits under the query it counts.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016jxMkwA2rbicdGxHosecYi
Both make a search spend its whole 40 000-star budget, twice over in the bisection, and the
CI runner timed out at the default five seconds. The crowds are now indexed in cells sized for the
ranges asked of them, as the real catalogue is, and the two tests carry their own 30 s timeout.
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 merge gate asks whether Gaia contributed any stars, never how many. The TAP service truncates
on its own timeout and still serves a well-formed CSV with a 200, ordered by magnitude — so a half
answer is the bright half, which is the half HYG overlaps. Every gate passes: Gaia stars are
present, HYG survivors go down rather than up, unmerged twins can only fall. The weekly job would
publish a catalogue missing two hundred thousand stars and the runner would cache it for the weeks
after. `fetchGaiaStars` now refuses fewer than 95% of the 412 765 rows its query holds, as its
sibling query already did, and refuses an answer that fills the row limit.
`fetchText` retried the request but not the body: a connection reset part-way through the 57 MB
CSV rejected out of the loop, with no wait and no second attempt. The read now happens inside it.
Also corrected: the merge gate's account of the HYG survivors (two thirds of them are stars Gaia
measures but the main query never downloads, since Gaia puts them past the 250 pc cutoff), and the
refresh workflow's comment on what happens when the archive is unreachable.
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