A layer's world clock coverage may now give each mark as an object,
{ time, label?, id?, kind? }, as well as a bare epoch ms number, and the
two may be mixed. worldClock.coverage() keeps marks as the sorted list of
distinct times, so existing readers are unchanged, and adds markDetails:
the merged marks in time order (then kind, label and id), each frozen and
holding only the fields given. Marks given alike by several sources appear
once, a bare time is dropped where a labelled mark shares it, and a mark
with no finite time is ignored. The contract is documented in the
worldClock JSDoc and docs/APPLICATION.md.
Launches label their marks with the mission's name (the launch's where it
has none), cut to 27 characters in capitals as the mission index shows
names. Earthquakes of magnitude 6 and up label theirs with the magnitude
as the map shows it and the feed's place cut to 40 characters, such as
"M6.4 · 113 km SSE of Lata, Solomon Islands"; the layer now tells the clock
when the labels change as well as the times.
On the timeline, a pointer within 6 px of a tick shows its label over the
track (nothing for an unlabelled mark), and a tap there goes exactly to
the mark's time instead of the point tapped. A tap elsewhere and a drag
work as before, and ticks stay ticks. The arrow keys still step from mark
to mark; with the handle on a mark, its labels follow the time in the
handle's aria-valuetext, and show over the track while it has focus.
Changelog fragments
One file per entry. A pull request adds a file here instead of editing
CHANGELOG.md, and a release concatenates them into it.
changelog.d/<pull request number>-<slug>.md
723-atc-decision-layer.md, for example. The slug is lowercase, words separated
by -. Two pull requests never pick the same filename, because the pull request
number is already unique — which is the point: new CHANGELOG.md entries go at
the top of the file, so two pull requests in flight write into the same few lines
and git has nothing to merge on.
Write the file exactly as the entry should read in CHANGELOG.md: a - bullet,
wrapped the way the surrounding entries are, crediting yourself and the pull
request.
- Report which upstream declined a Street Traffic road load. The layer row now
reads `Overpass rate-limited` instead of a general "Road data temporarily
unavailable" (yourname, #665).
The text is spliced in unchanged apart from trailing whitespace, so what you
write here is what ships. Fragments are deliberately outside
scripts/format-scope.json, so npm run format never reflows one.
At release time:
npm run changelog:check # list what would move, change nothing
npm run changelog # move every fragment into CHANGELOG.md
The assembler refuses a batch rather than guessing: a filename that is not
<pull request>-<slug>.md, or two fragments claiming one pull request number,
stops the run before anything is written and names the files.
If npm run changelog fails part-way (a full disk, a killed process), run it
again. The batch is staged in changelog.d/.assembling/ and only lands when the
assembled file replaces CHANGELOG.md in a single rename, so the rerun either
finishes that batch or puts its fragments back first. It never adds an entry
twice or drops one. npm run changelog:check names a staged batch, if one is
left over, instead of reporting past it.
A documentation claim that needs a regression test — the way
src/annotations/drawTool.test.mjs asserts against CHANGELOG.md — should
assert against docs/CURRENT-STATE.md or README.md instead. A pull request
still edits those directly, so the text is in the file while the change is under
review; a fragment does not reach CHANGELOG.md until release.