Units: implemented on both apps, the web interface and the editor - planned becomes agreed

spec/units.yml is agreed: the Android, iOS and web-interface tables were compared
line by line with the spec (49 units, symbols, scale, offset, system,
counterpart) and match; the editor generates its table from the file. The
unit-reference rule records the conforming revisions and tests, the three
test-matrix rows (unit-reference-parse, unit-conversion-display,
unit-conversion-ui) are active with both platforms' tags in place, and the
units page and next.md say the implementations exist. With the agreement
flipped, _check_units now fails the build on a missing or differently spelled
English symbol; it passes.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

Author: Staacks

CLAUDE.md

@@ -417,4 +417,7 @@ proven against the corpus on every build) is done, and so is phase 4b's app half
 both apps run the corpus in their own test suites with T0 CI, kept in step by `test-matrix.yml`
 and its checker. What is left of 4b is wiring the corpus into the editor test suite (deferred
 until the editor is picked up again), and phase 5, making the Blockly editor consume the spec
-instead of encoding the format a fifth time.
+instead of encoding the format a fifth time. Phase 5 has its first piece since 2026-09-30: the
+editor's unit picker is generated from `spec/units.yml` (`scripts/generate-units.mjs`, with a
+test that fails when the committed table drifts from the spec) - the pattern the rest of
+phase 5 should follow.

docs/file-format/units.md

@@ -4,8 +4,9 @@
     Unit references are part of file format 1.21, which the
     [next release](../reference/version-history/next.md) carries. A file using them must declare
     that version, and every app released before it refuses such a file. This page was written
-    ahead of the implementations (2026-09-30): it is the design the apps, the remote interface and
-    the editor are built from.
+    ahead of the implementations (2026-09-30), which followed it the same day on both apps'
+    development branches, in the remote interface and in the editor; it remains the definition
+    they are checked against.
 
 Several view elements show a unit next to a number: the [value](views/basics.md#view-element-value)
 and [edit](views/user-input.md#view-element-edit) elements with their *unit* attribute, and the
@@ -68,8 +69,9 @@ added with 1.21 have no placeholder form, only the reference.
 
 ## Known units
 
-The table is generated from `spec/units.yml`, which is the single source for the validators and
-for the conversion tables of the apps and the remote interface. Units of one quantity convert
+The table is generated from `spec/units.yml`, which is the single source for the validators,
+for the editor's unit picker (generated from it at build time) and for the conversion tables of
+the apps and the remote interface, which copy it. Units of one quantity convert
 into each other through the quantity's base unit; the *conversion* column gives the factor to
 that base unit. *System* is metric, imperial or common (neither — a unit the unit-system setting
 never touches); *counterpart* is the unit the app switches to when the user forces the other

docs/reference/version-history/next.md

@@ -54,7 +54,8 @@ interface and in the editor from that specification:
 - **`spacing`** on vertical, horizontal and grid inserts a gap between the children, in text
   line heights (see [Sizing](../../file-format/views/groups.md#sizing)).
 
-Specified 2026-09-30 ahead of the implementations (Android first, then iOS and the editor):
+Specified 2026-09-30 ahead of the implementations and implemented from that specification the
+same day on both platforms, in the remote interface and in the editor:
 
 - **Unit references:** the *unit* attributes of value, edit and graph (*unit*, *unitX*, *unitY*,
   *unitZ*, *unitYperX*) take `@id` naming one of the [known units](../../file-format/units.md)

spec/rules.yml

@@ -420,13 +420,28 @@ rules:
     applies_to: "every attribute with type: unit"
     state:
       android: >-
-        Not implemented (2026-09-30): PhyphoxFile.translate() resolves the
-        placeholder to a string after the translation-block lookup and the
-        elements store strings. Planned; see the Android handoff.
+        Conforms as of the development branch (326a4c3c, 2026-09-30): the
+        unit attributes are parsed to a Unit (Units.java holds the table
+        from spec/units.yml), `@id` at file format 1.21 and the deprecated
+        placeholder in any version resolve to it, everything else stays
+        text; the Unit system setting (key unitSystem) and the per-element
+        dialog convert what the elements display, the remote server emits
+        the logical unit. Tests: UnitReferenceParseTest,
+        UnitConversionDisplayTest, GraphUnitConversionTest (Robolectric),
+        UnitConversionUiTest (instrumented).
       ios: >-
-        Not implemented (2026-09-30): ExperimentTranslationCollection.
-        localizeString() resolves the placeholder to a string and the view
-        descriptors store strings. Planned; follows Android.
+        Conforms as of the development branch (f995e6a8 and 8f290c93,
+        2026-09-30): Helper/Units.swift holds the table, the view
+        descriptors carry the logical unit, the Settings-app entry
+        unitSystem and the dialog convert the display, the web server emits
+        the logical unit. Tests: UnitReferenceParseTests,
+        UnitConversionDisplayTests (XCTest), UnitConversionUITests.
+      editor: >-
+        The unit attributes offer a preset picker generated from
+        spec/units.yml (ed3b152, 2026-09-30; scripts/generate-units.mjs
+        with a --check mode and tests/units.test.ts comparing the committed
+        table with the spec); `@id` and the placeholder load into the
+        preset, the editor writes `@id`.
     check: >-
       Adding a unit means a row in spec/units.yml AND a string
       common_unit_short_<id> in both app string tables; the docs build

spec/units.yml

@@ -10,8 +10,12 @@
 # interface), which must carry exactly these numbers.
 #
 # Decided by the maintainer 2026-09-29/30 (specification ahead of the
-# implementations, like the view groups). No app reads unit references yet;
-# `agreement: planned` flips to agreed once both apps ship them.
+# implementations, like the view groups). Implemented from it on both apps'
+# development branches, in the web interface and in the editor by
+# 2026-09-30 (Android 326a4c3c, iOS f995e6a8, webinterface c4bf958, editor
+# ed3b152); the editor generates its table from this file
+# (scripts/generate-units.mjs), the apps and the web interface copy it and
+# were compared line by line when the agreement was flipped.
 #
 # Fields per unit:
 #   id           the reference is `@<id>`; the app's symbol string resource is
@@ -44,7 +48,7 @@
 
 units:
   since: "1.21"
-  agreement: planned
+  agreement: agreed
   systems: [metric, imperial, common]
   quantities:
     - {name: length,                base: meter}

test-matrix.yml

@@ -57,21 +57,22 @@ tests:
     area: file-format
     tier: T0
     platforms: [android, ios]
-    status: planned
+    status: active
     description: >-
       The unit attributes are parsed to logical units (spec/rules.yml,
       unit-reference; spec/units.yml): in a 1.21 file `@meter` yields the
       known unit meter, shown with the app's symbol; `[[unit_short_meter]]`
       yields the same unit in any version; a literal `m`, an `@meter` in a
       file declaring 1.20, and an unknown `@metre` in a 1.21 file are custom
-      text, shown verbatim and not convertible. Specified 2026-09-30 ahead of
-      the implementations; flip to active once both parsers carry the tag.
+      text, shown verbatim and not convertible (UnitReferenceParseTest /
+      UnitReferenceParseTests). Specified 2026-09-30 ahead of the
+      implementations, active the same day.
 
   - id: unit-conversion-display
     area: ui
     tier: T0
     platforms: [android, ios]
-    status: planned
+    status: active
     description: >-
       What the view elements DISPLAY follows the unit conversion
       (docs/file-format/units.md, "Conversion in the app"), checked on the
@@ -86,15 +87,16 @@ tests:
       slope unit once an axis is switched, and that text units, a value
       with positiveUnit/negativeUnit and an edit with decimal="false" are
       untouched. Android: Robolectric against the elements and GraphView
-      (like GraphTicLabelTest); iOS: XCTest against the view descriptors
-      and the graph module. Specified 2026-09-30 ahead of the
-      implementations.
+      (UnitConversionDisplayTest, GraphUnitConversionTest); iOS: XCTest
+      against the view descriptors and the graph module
+      (UnitConversionDisplayTests). Specified 2026-09-30 ahead of the
+      implementations, active the same day.
 
   - id: unit-conversion-ui
     area: ui
     tier: T1
     platforms: [android, ios]
-    status: planned
+    status: active
     description: >-
       The user-facing path of the unit conversion on the running app
       (Espresso / XCUITest, on the emulator or simulator, with
@@ -106,7 +108,9 @@ tests:
       change (the buffer value read back through the remote interface or
       the export is the original); the Unit system setting converts every
       convertible element on the next experiment load and leaves the
-      exclusions alone. Specified 2026-09-30 ahead of the implementations.
+      exclusions alone (UnitConversionUiTest / UnitConversionUITests).
+      Specified 2026-09-30 ahead of the implementations, active the same
+      day.
 
   - id: corpus-invalid-reject
     area: file-format