The lane vocabulary is the served payload, not the shipped set
What a port may declare and what an implementation ships are different questions. Answering the first with the second is how a site could add a lane it could never use.
The rule
- The declarable lane vocabulary is the served port configuration: the shipped lanes, the port-shape registry (code-declared shapes first, then site-declared ones), and the site's stored overlay, composed in that precedence order.
- Whether a port may declare a lane is asked of that payload, never of the shipped set alone: otherwise a site can add a lane, colour it and write rules for it while no port is able to declare it, the declaration being silently replaced by the schema-derived lane with a wrongly coloured handle as the only symptom.
- A lane the payload does not declare is still refused, because such a port would be compatible with nothing, not even with another port of its own lane.
What it means
A lane a port may declare is decided by asking the served configuration — the shipped lanes, the shapes any component or the site has added, and the site's own overlay — never by asking the shipped set on its own. A site that adds a lane through its overlay, colours it and writes compatibility rules for it gets a lane a port can actually declare; a name that fits none of the three sources is refused outright, even where it is otherwise well formed, because such a lane could not be compatible with anything else in the workflow, not even with another port of its own kind.
Example
A site declares one extra lane, order, in the served vocabulary.
["order"]"order""json"The undeclared name falls back to whatever the underlying schema type implies, the same outcome as if the port had declared nothing at all.