@@ -7,12 +7,14 @@ image to a consumer-supplied adapter and stores only the key the adapter
 returns. No image bytes ever cross the MetaObjects wire — the field, the
 generated Zod schema, and the REST payload all carry a plain string.
 
-This is a **TS-web-only** feature. The metamodel vocabulary (`view.image` and
-its five attrs) is registered by the `metaobjects-ui-web` provider and applied
-only in TypeScript; the non-TS ports carry a byte-identical mirror of the spec
-file for drift parity but never apply the provider, and none of them ship an
-upload widget. A `field.string` authored with a `view.image` child is, to a
-Java/Kotlin/C#/Python port, just a plain string field.
+This is a **TS-web-only** feature — the upload widget, crop UI and adapter
+contract exist only in the TypeScript web client, and no other port ships one.
+The `view.image` subtype itself LOADS in every port (all the generic `view.*`
+controls register for loading everywhere; they stay manifest-excluded as
+PRESENTATION_ONLY — `fixtures/registry-conformance/README.md`), but its five
+attrs (`@aspectRatio` … `@maxBytes`) are registered only by the TypeScript
+`metaobjects-ui-web` provider, so a `view.image` carrying them is authorable in
+TypeScript alone. A backend port reads the field as the plain string it is.
 
 ## Authoring: `field.string` + `view.image`
 
 
@@ -67,10 +67,14 @@ the owning field's subtype, so a boolean default stays a boolean rather than bei
 
 ### `view.base` is the one genuine removal
 
-`view.base` was a view carrying no kind. Core registers only `view.base` and `view.currency`; the
-other view subtypes (`view.text`, `view.textarea`, `view.checkbox`, `view.radio`, `view.image`, …)
-come from the TypeScript-side UI provider. A project on a port that does not apply that provider
-therefore has `view.currency` and nothing else until it does.
+`view.base` was a view carrying no kind. At this migration's cut, TypeScript registered all the
+concrete view subtypes while the non-TS ports registered only `view.base` and `view.currency` — so
+a backend port rejected `view.text` with `ERR_UNKNOWN_SUBTYPE`. That asymmetry is since gone: every
+port now registers the generic `view.*` controls (`view.text`, `view.textarea`, `view.checkbox`,
+`view.radio`, `view.image`, …) for LOADING, still excluded from the cross-port manifest as
+PRESENTATION_ONLY (`fixtures/registry-conformance/README.md`), while the attrs ON those controls
+remain registered only by the TypeScript UI provider. The removal stands unchanged: `view.base`
+itself is refused in every port.
 
 Nothing is lost that carried information — a `view.base` node declared no kind and no attrs, and
 the JVM never accepted one — but if you were using it as a placeholder, delete it rather than
 
@@ -39,8 +39,9 @@ public static class RegistryManifest
     //    them as such; `description` stays in commonAttrs);
     //  - `metadata.base` is a per-port inheritance anchor (Java's), not in the
     //    cross-port contract — other ports register only `metadata.root`;
-    //  - the 11 generic `view.*` controls are a TS-web-presentation facet (cut
-    //    cross-port; C#/Python deregister them, TS keeps them registered).
+    //  - the generic `view.*` controls are a TS-web-presentation facet. C#
+    //    registers them for LOADING only (CoreTypes, via ViewConstants); this
+    //    filter is what keeps them out of the cross-port manifest.
     // ------------------------------------------------------------------
 
     // Wave 3b — the in/out boundary is an EXPLICIT CLASSIFICATION (a reason
 
@@ -110,10 +110,12 @@
  *       ADR-0001/ADR-0005, kept registered but excluded from the manifest) were
  *       reconciled in SP-G Unit 6b/6b-finish; the {@code value*}/{@code data*}
  *       vestigial sets were refactor-dropped (Unit 6b).</li>
- *   <li>Subtype gaps/extras: Java lacks {@code attr.stringarray} and the 11 generic {@code view.*} subtypes
- *       (checkbox/date/dropdown/hidden/hotlink/month/number/password/radio/text/
- *       textarea/web), and carries an extra {@code metadata.base} (its
- *       inheritance anchor; the other ports register only {@code metadata.root}).</li>
+ *   <li>Subtype gaps/extras: Java lacks {@code attr.stringarray} (retired
+ *       vocabulary) and carries an extra {@code metadata.base} (its
+ *       inheritance anchor; the other ports register only {@code metadata.root}).
+ *       The generic {@code view.*} presentation controls — which Java formerly
+ *       did not register (SP-G B-2) — now register for LOADING only
+ *       ({@code PresentationView}) and stay excluded from the manifest.</li>
  * </ul>
  * <p><strong>SP-G Unit 6a reconciled</strong> (registration-only structural items):
  * required-ness flips ({@code identity.primary/secondary/reference.fields},
 
@@ -124,3 +124,16 @@ node that declares an anchor rather than a thing has no meaning for codegen or r
 
 **Report the divergence and change nothing.** Rejected: the report was the cheap half, and leaving
 one document with two verdicts is the failure the corpora exist to prevent.
+
+## Amendment 1 (2026-10-04) — the concrete `view.*` controls now load in every port
+
+The Consequences paragraph above states that the ports without the TS-side UI provider have
+"`view.currency` and nothing else." That was the SP-G B-2 deregistration ruling, and a
+loader-parity fix has since superseded its registration half: every port now registers the generic
+`view.*` controls (`view.text`, `view.dropdown`, …) for LOADING, so one document carrying them
+loads everywhere. They stay TS-web-presentation-only — no backend consumer reads them — and stay
+excluded from the cross-port manifest as PRESENTATION_ONLY
+(`fixtures/registry-conformance/README.md`); the attrs ON those controls remain registered only by
+the TypeScript UI provider. Nothing here reopens the `view.base` removal: the anchors stay
+authorable-nowhere, and this amendment only retires the claim that a backend port cannot load a
+concrete view.