v0.8.0

• Checking a component on its own. ddd check --standalone holds back the checks that
  need every component of a project, derived from the registry the way the language server
  derives them, and an explicit -W on the same run still wins. The CMake module's
  per-component target uses it instead of naming two checks by hand, so a component that
  takes a type, a unit, a section, a constant or a raster from the project's vocabulary checks
  clean alone. An empty address map is a first run rather than a map with holes: it raises no
  address-missing, so a strict two-run flow passes the seeded first build.

• The published schemas accept what the loader accepts. An empty conversion, the
  enumerators of an enum as a {"NAME": value} mapping and a unit as a bare spelling were
  read by ddd check and refused by the schemas ddd schema publishes, so an editor bound to
  them underlined every recommended shorthand; the conversion union is published as anyOf
  and the two shorthands beside their object forms. The example projects carry identities,
  and the tests re-run every command the documentation shows over them.

• Quick fixes follow the checker on limits. A declaration that leaves the limits out
  defers to the one that states them, which definition-mismatch counts as agreement; the
  editor no longer offers to spread or strip a range in that case, and only two stated ranges
  that differ are offered a fix.

• Fixes from a whole-project review. A section name is spelled with letters, digits,
  ., _ and $, since the generated C writes it into a string literal; an enumerator
  value, a raster event and a section alignment are integers rather than quoted numbers, as
  the published schemas already said; a raster cycle is matched whole. Findings at one
  place are listed in the order they were reported, so reused-name precedes the removal
  it explains; a plain object's consumers are sorted, as the dictionary documents; a spelled
  dimension has to agree with the numeric one in an archived dictionary. ddd id --assign
  fills an explicit "id": null and keeps each line's own ending. In --renames, a member
  of a renamed structured variable is listed under the instance's id followed by its member
  path. A baseline is analysed without --strict and the comparison runs on whatever
  resolved. The a2l keeps one COMPU_METHOD per display format, caps every synthesised
  identifier at 128 characters, leaves out a curve whose axis is unknown rather than writing
  it incomplete, and a2l-unrepresentable follows the file's own export closure; a
  structure member's enumerators and limits are held to its storage like a declaration's.
  The language server survives a plugin that raises during a hover, keeps its wire clean of
  whatever a plugin prints, refuses a negative Content-Length, matches a symlinked
  document to its build, keeps every workspace folder, and keeps the host of a file://
  uri. The CMake module passes the a2l options only when the a2l is generated. A plugin
  cannot be named c, a2l or all, and two plugin files whose paths differ only in
  punctuation are two plugins. The example plugin reports a key claimed twice in an
  archived baseline and honours an object's condition in the header it writes.

• Plugins. A project names python modules under plugins, each owning an extensions
  block on a definition and on the project that DDD validates against the plugin's own
  pydantic model, carries into the dictionary in resolved form and never interprets. A plugin
  contributes checks, reported and policed like the built-in ones under identifiers spelled
  <plugin>/<check>; comparison rules, run after the built-in comparison; and an artefact,
  selected as ddd generate <name>. Five built-in checks arrive with it: plugin-not-found
  and plugin-invalid, with a fixed severity, unknown-extension, consumer-extension,
  and missing-plugin, which says when a compared dictionary was produced with a plugin the
  run has not loaded. ddd schema --plugin publishes a schema closed over a project's
  plugins, ddd compare --plugin loads them for an archived candidate, and
  ddd checks --plugin lists their checks. examples/plugins/ddd_layout.py is a worked
  example. Migration: none for an existing project - no key is required and nothing is
  stamped. The dictionary format moves from 6 to 7: every object, every instance and the
  dictionary itself carry extensions, and the dictionary records plugins; a dictionary
  dumped by an older DDD reads back with all of them empty.

• id on a producing declaration: the identity of a data object, which survives a
  rename. Twelve lowercase base32 characters, opaque, written by ddd id --assign rather
  than typed by hand. duplicate-id refuses two objects of one project sharing one, and
  consumer-identity refuses it on an input declaration, the same reasoning that already
  refuses init and section there; missing-id reports a producing declaration that states
  none, at info, so an unmigrated project sees it without being held to it. ddd compare
  now pairs objects on the id before falling back to the name, so a rename is one
  renamed-object finding with the ordinary interface comparison still run across it, rather
  than a removal and an addition that never meet; a name freed by a rename and claimed by a
  different object is reused-name, an error, because a calibration dataset or a recording
  keyed by that spelling binds to the new object exactly as readily as it did to the old one.
  Migration: the dictionary format is 6, and every object of a freshly dumped dictionary
  now carries id, null where nothing was stamped, exactly like section or raster; a
  leaf of a structured object carries the same thing under instance_id. Run
  ddd id --assign over the description files once and commit the result; until then
  missing-id reports at info, which a migrated project turns into its gate with
  -W missing-id=error. A baseline archived at format 5 or older carries neither key at all,
  which is not the same as having none stated - its objects pair by name and no rename is ever
  inferred against it.

• ddd id --assign FILE... writes an id into every producing declaration and instance
  that has none, editing the files in place; a declaration that already carries one is left
  alone, so a second run changes nothing.

• ddd compare --renames PATH writes the old-to-new name pairs of the comparison - each
  object's id, its old name and its new name - so a calibration dataset, a recording or a test
  script keyed by the old spelling can be migrated without parsing the comparison's own
  findings.