v0.30.0

No schema change: x-schema-version stays 1.16, and every manifest and lesson
valid under 0.29.0 is valid under 0.30.0. What moves is the shape of a
validation issue (an optional params) and three issue paths.

Issue parameters: the values a message names, as data (engine#201)

A validation issue gains an optional params: the values its message
interpolates, unformatted (E-MATCH-DUP-LEFT carries { term, positions },
E-CARD-REF carries { cardId }). 27 of the 59 rule ids put a runtime value
into their message; all but E-SCHEMA now also pass it as params (its message
and parameters are ajv's, deliberately not engine API). W-PROMPT-DUP, whose
two messages are constant, carries its variant (field), so 27 ids carry
params in all; E-VAR-KIND carries its variant (reason) next to the name. A
new test fails when a message can carry a value without params, and when the
params table in the rule catalog disagrees with the code
(src/issue-params.test.ts). The
keys per id are in the rule catalog, issue parameters.
Messages are unchanged.

Why: a consumer that words problems itself, like the reference app with its
own message catalog in eleven languages, could only get the repeated term or
the missing card id out of the English message text (adaptive-learner#3222,
#3247).

No two issues the engine's own rules report are indistinguishable any more
(E-SCHEMA and extension issues aside), which changes three paths and one
count:

• E-CARD-REF points at the entry, /card_ids/{i} (was /card_ids for every
  unknown id of an exercise).
• E-TILES-ORDERING points at the entry, /accept_orderings/{i} (was the
  exercise).
• W-VAR-UNUSED points at the variable, /variables/{i} (was /variables).
• A reference repeated within one field ({{b}} {{b}}, {{a + 1}} {{a + 1}})
  is reported once, not once per occurrence (E-VAR-UNDEFINED, E-VAR-REF).

A problem that is a relation between several elements keeps its path and is
told apart by its params (two E-MATCH-DUP-LEFT groups in one exercise, two
duplicated stable_ids). Measured before the change: no consumer depends on
the changed part of these paths. The content template maps warnings to an
exercise by the prefix /steps/N/exercise, which the new paths keep, and the
app reads no issue paths yet. The ten content repositories carry none of these
issues, so they need no re-pin for this release.

Correction to 0.28.0: something did compare a pin with the current release

The 0.28.0 entry "Docs: the pin and currency discipline" says that comparing a
pin against the current release is something "nothing performs today". That
did not hold when it was written. The reference app's Dependabot had opened
grouped /frontend update PRs that carried engine bumps since 2026-07-11
(adaptive-learner#1562, #1587, #2923), although they arrive 3 to 10 days after
a release and fail the app's pin and schema parity tests every time. And the
content template and the hub had carried engine-currency.yml, which compares
the pin with the tracked npm dist-tag, since 11:08 UTC on 2026-09-23, about 90
minutes before 0.28.0 was published. docs/architecture.md ("Pinning and
currency") carries the measured account.

Docs

• docs/architecture.md, "Rule ownership": a unification can let the worse
  version win (the hint-length case, measured: the engine's version reported 44
  warnings, all false; the template's copy none). Moving a rule now has three
  conditions: every version measured per repo over the real content, precision
  and completeness recorded separately (and where a false hit went), and the
  severity checked at the new place. The app holds three versions of the
  engine's rules, its backend's Pydantic models among them (engine#197, #198,
  #199, #206).
• "Pinning and currency": the record of the currency check, the condition
  under which a scheduled run can prove the create path at all, and
  Dependabot's engine PRs as a signal that arrives late and red (#198, #204).
• Every subpath export is documented: the /rules row names all seven, and
  docs/qti.md gains an API table with all ten /qti exports; the README
  exports gate covers the subpaths, and a changelog gate fails on a heading
  repeated within one release section (#200).