A node property's `type` key is asked to do two unrelated jobs at once: 1. **JSON Schema `type`** — a structural claim. Closed at seven values by the spec: `string`, `number`, `integer`, `boolean`, `null`, `object`, `array`. 2. **Editor port lane** — a compatibility and colour label. Open, ~25 members: `string[]`, `image`, `email`, `datetime`, `messages`, `any`, `mixed`, `tool`, `trigger`, … The two are reconciled by one closed map, `NodeMetadataResolver::mapSchemaTypeToDataType()` (SCH-10), whose miss branch is `?? "string"`. A silent fallback on a vocabulary mismatch cannot report a mismatch — so a plugin that writes a lane name into `type` gets a wrong port, silently, and no test notices. Adding `message_from_text` (#3592414) is what surfaced this: `messages` is the first member of the class with no plausible primitive to hide behind. It is not the first occurrence. ## Five mistyped ports, shipped today Neither `json` nor `any` is a key in the map, so all five declarations fall through to `string`. Traced through the map and its only caller, `transformSchemaToPorts()`, which does no special-casing. | Declaration site | Declares | Derives | Meant | |---|---|---|---| | `MessageFromText.php:200` — the `message` output | `json` | **`string`** | `json` | | `Reason.php:310` | `json` | **`string`** | `json` | | `Reason.php:235` — `loop_back` | `any` | **`string`** | `any` | | `ForEachNode.php:257` — `loop_back` | `any` | **`string`** | `any` | | `NodeMetadataResolver.php:330` — the injected reserved `loop_back` (SCH-32) | `any` | **`string`** | `any` | Two consequences follow directly: - `message_from_text`'s object output is a **string** port. Its commit message and MEM-16 both say `json`. - The `any` lane has **no members at all**. `NodesController::getPortConfiguration()` declares `any` and synthesises a compatibility rule into it from every other declared type — the code comment says outright that this exists so a loopback port accepts a gateway branch. No port ever carries the lane, so that machinery is dead code. ## The part that needs confirming at the canvas first The editor's checker is exact-match with no loopback bypass: `PortCompatibilityChecker.areDataTypesCompatible()` (`libs/flowdrop/src/lib/utils/connections.ts:116`) returns `false` for any pair it has no rule for, and `isLoopbackEdge()` is only used to classify cycles — it never skips the dataType check. A gateway branch is typed `trigger`. A `loop_back` port is typed `string` (per the table above). `trigger → string` has no rule. On that reading, **every hand-dragged loopback edge is refused by the editor.** `LoopBackInputInjectionTest` asserts injection, port order and exposure; it asserts nothing about `dataType`, so nothing catches it. This consequence is read off the source and has **not** been reproduced on a canvas. Confirm it before acting on its severity — if it holds, this is a shipped loop bug rather than a typing nit. ## A third vocabulary, unpinned and already drifted SCH-10 pins two ends of a coupling that has three: | Site | Lane ids | |---|---| | `NodeMetadataResolver` map + `DATA_TYPE_OVERRIDES` | the derivation's range | | `NodesController::getPortConfiguration()` (served) | ~25, incl. `any`, `mixed`, `messages` | | `libs/flowdrop/src/lib/config/defaultPortConfig.ts` (fdnpm) | **22 — no `any`, no `mixed`, no `messages`** | SCH-10 pins 1↔2 by test. Nothing pins 3. Any editor running on the library defaults — the example server, any embedder that has not fetched the backend payload — sees a `messages` port as an undeclared type: compatible with nothing, not even another `messages` port. That is the failure SCH-10.a exists to prevent for stored config, arriving through the other door. ## Proposal — split the keys "`type` must adhere to JSON Schema" closes the structural half and makes the silent fallback impossible, but it cannot express the lane half, because `messages`, `image`, `email` and `tool` are not types. They are three different things wearing one hat: refinements of a primitive (`email`, `url`, `image` — JSON Schema already owns this: `format`, `contentMediaType`), shaped composites (`messages`, `string[]` — named schemas, `items`/`$ref`), and control lanes (`tool`, `trigger` — not data at all; the edge *is* the message). **Structural key.** `type` is closed to JSON Schema. `json` → `object`; `any`/`mixed` → omit `type`, which is JSON Schema's own way of saying "anything"; `tool`/`trigger` → declared by port kind, never by `type`. **Lane key.** `dataType` becomes derived, total, and loud — first match wins: 1. `x-data-type` naming a **declared** lane → that lane 2. else `format` / `contentMediaType` → refined lane 3. else `type: array` + `items.type` → `string[]` / `number[]` / `json[]` 4. else the primitive map (`object→json`, `integer→number`, …) 5. else **fail** — no `?? "string"` Absent `type` resolves to the `any` lane rather than falling to `string`, which is what all three `loop_back` declarations were reaching for. **`messages` is a named schema, not a lane needing a special case.** `DATA_TYPE_OVERRIDES = ["messages"]` is the right instinct in the wrong shape — a private const that grows one entry per semantic type, each needing a code edit in three places. Register the shape once (`array` of `{role: enum[user|assistant|system|tool], content: string, tool_calls?, tool_call_id?}`), keyed by the id the port config declares. That gives one definition instead of three prose restatements (MEM-5 step 1, MEM-16, `ReasonMessage::fromArray()`), makes payload validation possible, and finally feeds fdnpm's `NodePort.schema` field — declared for template autocomplete (`types/index.ts:169`) and never populated, because fddo's `NodePort` DTO has no such field. ## Specification registry Six rows for GR-SCHEMA: - **SCH-34** — a property schema's `type` is a JSON Schema type: one of the seven, or an array whose every member is one of the seven (extending SCH-9's union handling per member). Any other value is a test failure, not a silent `string`. Pinned by a reflection sweep over every shipped plugin's `getParameterSchema()`/`getOutputSchema()` — cheap, and it catches every future offender rather than the five that exist now. - **SCH-35** — lane derivation is total and fails loud. Replaces SCH-10's `?? "string"` tail. Absent `type` ⇒ `any`, never `string`. - **SCH-36** — the lane vocabulary has exactly one declaration site: derivation range ⊆ it, served payload = it, and the editor's default config generated from it rather than mirrored by hand. Closes the untested third end. - **SCH-37** — control lanes (`tool`, `trigger`) are declared by port kind, never by `type`. - **SCH-38** — every non-primitive lane has a registered named schema; the lane id is that schema's key; MEM-5 and MEM-16 cite it instead of restating it; the port wire carries it so `NodePort.schema` is populated. - **SCH-39** — a one-way compatibility rule carries a stated reason. The `messages→array|json` pair already has an excellent one, living in a code comment; making it a required field stops a widening rule being added silently, and widening is the direction that loses safety. ## Sequencing 0. **Fix the five literals.** Write the failing assertions first (`loop_back` carries `any`, `message` carries `json`), confirm they fail, then fix. Before any of it, drive one gateway→`loop_back` edge in the editor and settle whether the refusal above is real. 1. **SCH-34/35 as a reflection sweep** — the phase that converts the class from invisible to CI-visible. 2. **One vocabulary, generated downstream** — single declaration site, generated `defaultPortConfig.ts`, SCH-36's pin. Crosses the fddo/fdnpm boundary. 3. **Named-schema registry** — `messages` registered as a shape, `NodePort.schema` on the wire, `DATA_TYPE_OVERRIDES` retired.