0.8.2 — the same grey in both places

Fixed

• The header button's glyph is the same grey as the command list's. The list is painted by the
  Sidebar's own icon slot, which uses the tertiary label colour, while the button inherited the primary
  one — so the same play icon read darker there than in the menu. Both now measure rgb(129, 133, 140).
  The status dot keeps its own colour, which is the point of it: it still measures the same green the
  rows use.

0.8.1 — the glyph is what the slot centres

Fixed

• Every row's icon is centred on its title. The glyphs are drawn by inline SVGs, and an inline SVG
  keeps a line box under its drawing: the icon slot centred that box, so the glyph itself sat about a
  pixel and a half high in every row — most visible with the asterisk the default icon uses. A glyph is
  a block now, so the drawing is what the slot centres. Measured: the glyph's centre moved from 1.5px
  above the title's to 0.5px below it, the same half-pixel the slot itself reports.
• A console whose harness cannot serve the output says so. "No output yet" looks the same whether
  a command has not printed yet or the host predates the request for its output. The console now tells
  the two apart and, in the second case, names the reason and the remedy: this harness is older than
  this console, restart the harness.

0.8.0 — one route, the one that works

Changed

• A console reads through the route the menu already uses. It had a second route of its own —
  /log — and a console whose only job is to show a run was therefore the one surface that broke when
  something in between filtered that path: the fetch died, the client called it an unreachable host,
  and the console showed nothing for every command while the rest of the plugin worked. The command
  list now takes logs=1 and folds each run's tail into its answer, so a console needs one request to
  one route, and the plain list stays as light as it was for the header's poll.
• Against a host older than the client — the case a page reload creates, since the harness keeps the
  plugin it loaded at boot — the console falls back to the log route in either shape, and if that route
  is unreachable as well it shows the run's state without an error line, because a run's state is
  exactly what it cannot guess.

Added

• GET /commands?logs=1, documented in docs/configuration.md.

0.7.4 — read the log in whichever shape it arrives

Fixed

• A console reads whatever build answers it. Reloading the page brings a new client while the
  harness keeps running the plugin it loaded at boot, so a console could meet a host that predates it:
  that host serves the log route as plain text, the client asked for JSON, and the parse failure was
  reported as an unreachable host — with no output on screen, for every command. The console now takes
  the tail in either shape and, when the answer carries no run facts, reads those from the command
  list, which every version serves.

0.7.3 — a console that remembers

Added

• The console remembers what it read. A harness restart forgets every run, and the tab — which the
  Sidebar keeps — used to go blank and report the loss. It now keeps its last output per console and
  shows it while saying what happened, so a restart leaves a readable console and a Run again
  button instead of an empty panel.
• The console follows its own output, the way a console does: it keeps the newest line in view
  until the reader scrolls up to look at something older, and resumes following when they come back
  to the bottom.

0.7.2 — name what failed, and offer a way back

Added

• Run again, from the console. Whenever a console's command is not running, its bar offers to launch
  it again — after a finished run, and especially after the harness restarted and forgot the run. What
  used to be a dead end that only reported bad news is now a way back to a tracked, live run.

Fixed

• A console names what actually failed. Every failure that was not a 404 was reported as "Could not
  reach the harness", which was a lie whenever the host had answered: a 500 now reads "The harness
  answered 500", and only a genuinely unreachable host reads as unreachable. The raw reason stays in
  the tooltip.
• The body no longer repeats the bar. A forgotten run used to print its state twice, once in the bar
  and once in the body; the body now says the one thing the bar cannot — that the output went with the
  harness that ran it — and keeps whatever output it had already read.

0.7.1 — a lost run is not a broken host

Fixed

• A console no longer mistakes a lost run for a broken one. Restarting the harness forgets every
  run it was managing, so an open console's next read answers 404 — which the tab now reports as what
  it is ("This run is no longer known to the harness. It may have restarted."), with no error line and
  no lost output. A read that fails for any other reason — the host restarting mid-poll, a dropped
  connection — keeps the output already on screen, says it is retrying with the raw reason in its
  tooltip, and clears itself on the next good read.

Changed

• The console polls to match what it is showing: once a second while the run is alive, and every few
  seconds otherwise, so a finished console still notices the next run of its command.

0.7.0 — a console per run in the harness's Sidebar

Added

• A console per run, in the harness's own right Sidebar. Launching a command now reveals the
  Sidebar on a tab named after that command: the same status dot the menu uses, the command line, a
  Stop button that asks first, and the run's output streaming while it is alive. Each command
  keeps its own tab — a second command opens a second console, re-running one focuses the console it
  already has — and the tabs belong to the session, so they survive a conversation switch.
• GET /log?format=json, which returns the same tail as output with the run beside it: the
  console needs both, and one round trip beats two.

Notes

• The console rides the Sidebar's documented public path — the tab type into ctx.sidebarRightTabs,
  the body and the chip into their keyed seats under the type's id — so it is a tab like any other and
  needs no third-party panel. Both services are injected optionally: a client without that Sidebar
  still runs commands, it just has no console to show them in.

0.6.4 — the header wears the status dot too

Changed

• The header control wears the status dot too. While the default command is alive, the button's
  play icon gives way to the same green dot the rows use, so "something is running" reads the same
  wherever you look. Stopping was already behind the confirmation everywhere, and the tooltip says so.

0.6.3 — every stop asks first

Changed

• Every way of stopping asks first. The header button joined the row and the status dot: pressing
  it while a command is alive opens the same confirmation, and only Stop ends the process. Its
  tooltip says so — "Ask before stopping npm run dev" — instead of promising a stop it will not perform
  on its own.