Manjunath
0c025987ef
Review follow-up for the sonar pulses. Bounded repaint: the pulses used to ask for a frame every 80 ms from a setInterval for as long as a subject was shown, so a parked view repainted at 12.5 fps indefinitely. They now run for 9 s (three ring flashes) after a selection or a camera move, fading in and out over 1.2 s, then rest: the ring stands on screen at full strength, the pulse lines and gradient disc are hidden, echoes stop, and nothing asks for frames. A moving subject does not wake them, since a flying subject moves on every refresh. The lifecycle's existing camera pose signature wakes them. No beat with the Cyber sonar: the setInterval is replaced by a postRender-armed setTimeout on CYBER_SONAR_RENDER_INTERVAL_MS, as in cyberSonarScene. Every drawn frame, whoever asked for it, re-arms the request 80 ms later, so requests never land inside the detection lane's 80 ms gate. Reduced motion mid-session: a change listener on the media query rebuilds the visual, and the same-subject refresh path rebuilds when the preference no longer matches. The listener is removed in clearVisual. Readable edge: restOpacity goes from 0 to 0.4, so the 250 km ring stays visible between flashes, in screenshots and for low-vision viewers. The echo field takes an optional level so echoes rest with the pulses. CURRENT-STATE and the changelog fragment describe the bounded run and the dimmed ring. Tests: render requests stop after the bound and stay stopped for a minute; a camera move seen by the lifecycle wakes them for another bounded run; a foreign frame postpones the next request to 80 ms after it; reduced motion flipped by event and by a later refresh; the ring never drops below restOpacity; echoes scale with the level; the level fades in, holds, fades out and keeps its value when woken.
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.