Proposal: let the install-form contract express the control it already promises

[justinmerrell]

Proposing that the install-form contract be able to say what it already promises a client will render — a picker, a labelled choice, a grouped form, and a value the platform fills in — and that the derivation rule this rests on move from a schema description into normative prose.

This is framed as reconciliation rather than new surface area, for the reason ADR 0013 gave about type: the rule is already the contract's stated behaviour, it is just written somewhere the repository declares non-normative.

Context: musher-dev/platform's console renders the deploy form entirely from schema today — it has no control field and wants none. musher-dev/catalog has 13 curated items waiting on the vocabulary.

---

1. The rule the whole design rests on is not a rule

ComponentInputUi carries one property, and its description says why:

The install-form control is derived from the input's schema (enum → select, BOOLEAN → toggle, EMAIL format → email field, sensitive → masked field) — only the label needs declaring.

That sentence is the entire contract between an author and a renderer. CONTRIBUTING.md ground rule 1 declares schema description fields informative. spec.md never states the mapping — component §6.1 says only that a USER input "needs a label before a form can render it", and grep -n 'select\|toggle\|widget\|render' specifications/*/v1/spec.md finds no clause.

So two conforming implementations may render the same document completely differently and neither is defective. That is the defect, independent of everything below, and it is worth closing on its own.

2. generator is renderable and platformDefault is not — and §5.1 already says why that is wrong

Blueprint §5.1 explains why a generated input is still derived into a parameter:

An input carrying a generator is derived, even though the user never types a value for it: a client rendering the install form still has to know it exists, and "three secrets will be generated for you" is a thing worth being able to say.

That reasoning is exactly right, and it applies word for word to platformDefault. But §5.1 derives only schema, ui and isRequired; BlueprintParameter has a generator property and no platformDefault counterpart at all. A platform-derived input is therefore structurally unable to reach the install form as anything other than an ordinary optional field.

The consequence, in musher-dev/catalog's n8n item — three inputs carrying platformDefault: PUBLIC_HOSTNAME / PUBLIC_URL:

Public hostname       [                    ]
Webhook base URL      [                    ]
Editor base URL       [                    ]

Three empty boxes, indistinguishable from an unset optional, in a form whose own help text has to say "leave blank to use this deployment's own generated hostname" in prose because the contract has no way to say it. "This is filled in for you, override it only for a custom domain" is at least as worth being able to say as "three secrets will be generated for you", and the specification currently grants one and withholds the other.

3. The measured corpus

Every USER input across the 13 items in musher-dev/catalog, at dc00d3f:

	count
USER inputs	28
…carrying generator (never typed)	11
…carrying platformDefault (never typed)	6
…a person actually types	11
of those 11: carrying enum	0
carrying format	1 (label-studio.adminEmail, EMAIL)
carrying pattern	0
type: BOOLEAN	1
type: NUMBER / JSON	0 / 0

All 13 blueprints declare parameters: {}, so every one of these forms is derived rather than authored.

Ten of the eleven typed inputs render as an undifferentiated text box. Of the four inference rules the ui description promises, enum → select is exercised zero times in the entire corpus, BOOLEAN → toggle once, EMAIL → email field once.

Two of the ten are the same field, independently hand-rolled by two authors:

# items/n8n/components/n8n.yaml
timezone:
  schema: { type: STRING, default: UTC }
  ui: { label: Timezone }
  description: IANA timezone for scheduled workflows

# items/openclaw/components/openclaw.yaml — same shape, same default

An IANA timezone is a closed set of ~400 terms that changes a few times a year. It cannot be an enum (nobody inlines 400 strings into every component document, and the list is not stable), it cannot be a pattern, and there is no format for it — so a specification that has a vocabulary for "this is an email address" has none for the single most common picker in configuration software.

Two more of the ten are URLs with no format: URI: mlflow.backendStoreUri and open-webui.ollamaBaseUrl. That is an authoring miss rather than a gap, and it is the kind of miss a generated field reference makes easy to keep making when the vocabulary is thin.

Eleven of the thirteen items already require zero typed input. The vocabulary is the remaining distance between the curated catalog and a one-click deploy.

4. The proposal

Three groups, deliberately separated by who may contradict whom. The load-bearing constraint is that nothing added to ui may change what a value means — presentation stays derived from schema, which is what makes drift between the data contract and the rendered control unrepresentable.

A. Semantic vocabulary, in schema — the control derives from these

Addition	Applies to	Rationale
format: TIMEZONE	STRING	Two items hand-roll it today. A renderer needs no list shipped with it: Intl.supportedValuesOf('timeZone') in a browser, zoneinfo.available_timezones() in Python, time/tzdata in Go. The spec would name the convention (an IANA Area/Location identifier) and nothing more.
format: HOSTNAME	STRING	n8n.n8nHost is a bare host, not a URI. The distinction is already load-bearing in platformDefault, which separates PUBLIC_HOSTNAME from PUBLIC_URL.
format: MULTILINE	STRING	A PEM block, an allow-list, a system prompt. Renders as a text area rather than a one-line box. Arguably the weakest of the three — see §7.
enumTitles	any type carrying enum	enum is array of string, so a select can only show the raw stored term. S3 / GCS / AZURE reaches a buyer as S3 / GCS / AZURE. Positional, same length as enum, structural.
minimum / maximum	NUMBER	ADR 0013 chose one numeric type on the reasoning that authors "write the constraint rather than reaching for a second type" — but the only constraint available is pattern, a regular expression over a number's string form. pattern: '^-?[0-9]+$' is the documented way to say "whole number"; there is no way at all to say "between 1 and 65535".

format stays null for non-STRING types — COMP-VAL-003 is unchanged, and numeric refinement is deliberately not a format member for that reason.

B. Presentation-only, in ui — these cannot contradict schema

Addition	Rationale
group	An eleven-field form is a wall. Grouping is the one thing a renderer cannot infer, because relatedness is not in the data.
order	Derivation order today is lexicographic node name, then mapping order within a node — an artefact of the merge, never an authoring decision.
isAdvanced	Distinct from isRequired. n8n's three URL overrides are optional and advanced; postgres.postgresDb is optional and not. Collapsing an optional field is currently a client-side guess.
placeholder	An example value, distinct from default — which is a value that is actually submitted.

Each is inert to validation. A renderer that ignores all four still produces a correct form.

C. platformDefault → a discriminated valueFrom

Generalise the existing field into a shape that names its kind, and give BlueprintParameter the counterpart it lacks:

inputs:
  webhookUrl:
    schema: { type: STRING, format: URI }
    ui: { label: Webhook base URL, group: Networking, isAdvanced: true }
    valueFrom:
      selfAddress:
        source: PUBLIC_URL
        endpoint: primary

Today's four sources move under selfAddress unchanged, with §6.1's endpoint-pairing rules and their three diagnostics carried over verbatim. The change buys two things:

1. A renderer can switch on it without parsing anything, which is what makes "auto-configured, override for a custom domain" expressible.
2. Room for the next kind — a value drawn from saved organization configuration, or from another node's published output — without a second field beside the first.

This is the shape the comparable contracts converged on: Kubernetes env[].valueFrom (fieldRef / secretKeyRef / configMapKeyRef), Render's fromService / fromDatabase, Heroku app.json's generator. A named-kind reference rather than a template string, precisely because a downstream renderer has to be able to read it.

generator stays where it is. It is not a reference to anything.

D. Mirror in blueprint/v1

§5.1 derives schema, ui and isRequired unchanged, so BlueprintParameterValueSchema and BlueprintParameterUi take A and B verbatim, and BlueprintParameter gains the valueFrom counterpart from C. The ERR_UNCOVERED_REQUIRED_INPUT table in §5.3 already reads platformDefault | absent as one of the five conditions, so that row moves with the field.

5. Why no ui.widget

Worth stating up front, because it is the obvious alternative and a reviewer will ask.

A widget enum is what react-jsonschema-form and Backstage's scaffolder use (ui:widget), and it is more expressive than anything above. It is rejected here because it makes presentation a second declaration of the same fact. schema: {type: STRING} beside ui: {widget: TIMEZONE} is a document that says a value is free text and says it is a timezone, and nothing can decide which is wrong. Under this proposal format: TIMEZONE says it once, and validation and rendering are the same statement seen from two sides.

The platform reached this independently: its ADR 0046 deleted a control field it had already shipped, on the grounds that "the console's form control could drift from the data contract because both were declared."

The cost is real and worth naming: a genuinely presentational choice with no semantic counterpart — "render this enum as radio buttons, not a select" — is inexpressible, and stays inexpressible. That looks like the right trade at this size.

6. Compatibility

Every addition in A, B and D is an optional field or a new enum member — additive, minor, no previously valid document becomes invalid.

C is breaking, and is the reason to raise it now rather than later. git tag -l is empty, published.json reads {"releases": {}}, and the manifest is 0.0.0 for all three families, so ADR 0005 §1's pre-publication window is open: no v2 directory, no migration note, maintainer approval and a breaking-change trailer. ADR 0013 put it exactly — "Adding members stays free forever; withdrawing one is free now and never again." If C is going to happen at all it costs a major version the day after the first tag.

Splitting is easy if that is preferred: A + B + D land as a minor on their own and are useful without C; C is separable and is the one that needs the window.

7. What a reviewer should push on

Three weak points, stated rather than left to be found.

format: MULTILINE is not like the others. EMAIL, URI, TIMEZONE and HOSTNAME each name a lexical convention a validator could check. MULTILINE names a shape a text box should have — it is a presentational fact wearing a semantic field's clothes, and by §5's own argument it belongs in ui or nowhere. It is listed under A because "the string may contain newlines" is arguably a statement about the value; I do not think that argument is strong, and dropping it or moving it to ui would not weaken the rest.

enumTitles as a positional parallel array is the weaker of two shapes. A list of {value, title} objects cannot go out of sync by construction; a parallel array needs a structural length rule to hold it together. The parallel array is proposed because enum is already published as array of string and changing its shape is breaking, while adding a sibling is not. If C is being taken anyway, the window makes the object form free too, and it is the better contract.

ui.group invites a group vocabulary. Free-text group names across a merged multi-node form will collide, near-miss ("Network" vs "Networking"), and be ordered by nothing. A closed vocabulary would be a lifecycleStage-shaped decision needing its own ADR; free text is proposed as the smaller commitment, and the failure mode is a slightly untidy form rather than a wrong one. If a maintainer would rather not open the door, dropping group and keeping order + isAdvanced still gets most of the benefit.

8. Process, as we read it

Recording our reading so it can be corrected rather than assumed:

• An ADR is required. Both C (a reshape of a published field) and any closed vocabulary of this shape fall under GOVERNANCE's structural-change and lifecycleStage-shaped rules. Happy to draft it against ADR 0001's format.
• Normative prose in both spec.md files — component §6.1 and §6.3, blueprint §5.1 and §5.3 — carrying the derivation rule from §1 with a COMP-UI-00N requirement ID, not only schema descriptions.
• schemas/src/ only, then task bundle; dist/ never hand-edited.
• At least one positive and one negative conformance fixture per new rule, each failing before and passing after, plus cases.json and a docs/traceability.md regeneration.
• .config/spelling/musher.txt entries for the new terms.
• DCO sign-off; feat(component): and feat(blueprint): scoped commits so both families release.

Happy to open this as one PR or as A+B+D first and C separately — whichever a maintainer would rather review. And happy to take a "no" on any individual item; the one that would be a shame to lose is §1, which costs nothing and is true regardless of the rest.

---

Related

• musher-dev/catalog — the 13-item corpus measured in §3; a companion issue will track backfilling each item once this lands.
• musher-dev/catalog#9 — the sibling of spec#72, still open.
• ADR 0013 (value-shape vocabulary) — the reconciliation precedent §1 leans on.
• ADR 0005 §1 (pre-publication window) — the reason §6's timing matters.

[justinmerrell]

Taking this seriously because it deserves it: the corpus was re-measured, every claim was checked against the repository, and the parts that are being declined are declined with reasons rather than on taste.

The core is accepted. §1 is a real defect and closing it is worth doing regardless of the rest, exactly as you say. §2's asymmetry is real. Most of §4 lands. What changes is where two things live, what four things are called, and one item's shape.

---

The evidence checks out

Re-measured against musher-dev/catalog at dc00d3f, the commit §3 cites. Every figure in the table matches: 28 USER inputs, 11 generator, 6 platformDefault, 11 typed; of those 11, zero enum, one format, zero pattern, one BOOLEAN, zero NUMBER/JSON; 13 of 13 blueprints declaring parameters: {}.

One correction, in a repository that measures its corpus: eight of the eleven typed inputs render as an undifferentiated box, not ten. postgres.postgresPassword carries schema.isSensitive: true and does get a masked control. So three of the four promised inference rules are exercised exactly once each, and enum → select is the only one exercised zero times. The argument is unchanged and slightly sharper.

Worth saying plainly, since the issue is careful everywhere else: enum labelling is the one addition with no corpus behind it. enum is written zero times across the thirteen items. That does not make it wrong — a chooser nobody can label is a reason authors reach for free text instead — but it is the one item arguing from design rather than from measurement, and it should not ride on the others' evidence.

§1 — accepted, and it cannot carry the requirement ID you ask for

§8 proposes landing the derivation rule "with a COMP-UI-00N requirement ID". It can't, and this matters more than it sounds, because getting it wrong makes the fix worse than the gap.

conformance/README.md:

An ID names a rule a document can violate. … Rules about what an implementation does rather than what a document contains … are normative prose and carry no ID, because an identifier whose permanent state is "excused" documents nothing.

No document can violate "a non-empty enum renders as a chooser". LIST-MEDIA-004 looks like a counter-example and is the repository's recorded anomaly rather than its precedent — listing §4.1's renderer clause, the actual first-of-kind and the one ADR 0004 §3 argues for, carries no ID at all. Adding a second permanently-UNPINNED entry would turn a wart into a pattern and move the explanation of the coverage line out of prose and into a TypeScript map.

So: normative renderer clause, no ID — and spend the COMP-UI prefix instead on rules a document can violate, three of which already have fixtures and are missing only a requirements array (component/structural/018, 019, 020). That converts a paragraph that could never be tested into six requirements that can, at no extra fixture cost for half of them.

It also wants a home of its own — a new §6.4 Install-form presentation, sibling to §6.3 — rather than a seventh subject inside §6.1. §6.1 is already suppliedBy, platformDefault, four sources and three semantic diagnostics; a renderer rule dropped in there reads as a document rule. §6.3 set the precedent when the shared schema block got a subsection instead of a home inside §6.1. As a side benefit ui finally gets a definition site: today its contents exist only in a schema description, which is the same defect this issue is closing, one field over.

§4A format — TIMEZONE and HOSTNAME in, MULTILINE out

Both new members pass §6.3's stated test more cleanly than two members already in the enum: ENDPOINT_URL and CONNECTION_STRING name roles, while TIMEZONE and HOSTNAME name lexical conventions. HOSTNAME also happens to match JSON Schema's own standard hostname format name.

MULTILINE is dropped on your own §7 reasoning. Nothing else weakens.

Two additions to the plan:

TIMEZONE carries an ADR 0003 obligation the issue doesn't mention. IANA decides membership and revises it several times a year — not when this repository releases. That is ADR 0003 placement two, and §2 is explicit: name where the vocabulary is published, "precisely enough to fetch: a URL a reader can open without an account", and "MUST NOT restate the members, not even informatively and not even dated". So the clause names the IANA Time Zone Database and enumerates nothing, exactly as blueprint §4.3 does for Compute Profiles. Your instinct is already right here — pointing at Intl.supportedValuesOf rather than a shipped list is the same conclusion — it just satisfies a written rule that should be cited.

The format member list becomes a table. It currently lives in a run-on sentence inside COMP-VAL-003's justification, while type gets a full table and a requirement ID of its own. ADR 0013's entire complaint was that membership stated informally is membership stated badly, and format is one sentence away from the defect that ADR fixed.

§5's argument for format over widget is right for a different reason

The conclusion stands, and one half of the reason doesn't:

Under this proposal format: TIMEZONE says it once, and validation and rendering are the same statement seen from two sides.

They aren't, today. §6.3's What v1 does not check says no phase tests a value against the shape its schema declares, and §7.2 confirms no schema this repository publishes uses the JSON Schema format keyword at all. A format member is currently exactly as unenforced as a ui.widget member would be. The case for format is the single-declaration half alone — one statement, in the field that owns the value's meaning — and it survives on that.

Enum labelling — both the shape and the home change

§7 offers the parallel array and concedes the object form is better. It's better still as neither: a mapping keyed by the member, in ui.

ui:
  label: Storage backend
  enumLabels:
    S3: Amazon S3
    GCS: Google Cloud Storage

On shape — the parallel-array form (enumNames) is non-standard and deprecated in JSON Schema tooling; where an extension is used in practice (Redocly and AsyncAPI's x-enumDescriptions) it is a mapping keyed by the value, recommended precisely because it "prevents length mismatch errors … compared to array formats which require exact ordering alignment". A mapping also gets duplicate-key rejection for free from the parser phase (ERR_DUPLICATE_KEY, component §7.1), so uniqueness costs nothing.

On home — this is the decisive part, and it also rules out the tempting move of making enum itself a list of {value, title} objects. Blueprint §5.2:

Two declarations are identical when their schema blocks are equal once defaults are applied. ui and isRequired are not compared: they describe how a value is asked for, not what it is…

Put labels anywhere inside schema and two components that declare the same enumeration with different wording become a hard ERR_CONFLICTING_INPUT_SCHEMA — a rejected composition over a difference of phrasing. In ui they are first-wins, which is the right answer for presentation. A second argument points the same way: ui is null on a CONNECTION input, so labels become unspellable exactly where there is no form to show them.

The one rule this needs is semantic, because JSON Schema cannot relate a mapping's keys to a sibling array's items: every enumLabels key must be a member of schema.enum, new code ERR_UNKNOWN_ENUM_MEMBER. A member with no label is legal and shows under its own spelling; a label with no member is the typo that would otherwise be invisible forever. Worth writing now — it is free only while the field has never shipped.

§4B — order and the disclosure flag in, placeholder renamed, group out

order — accepted, and it needs prose the issue doesn't supply: what an absent order means, and how ties break. COMP-ENVVAR-002 already writes down its own tiebreak on the grounds that anchors are normative rather than "left to whichever order an implementation iterates a mapping in", and this is the same situation. Blueprint §5 needs the companion clause, because a derived form has no defined order at all today — parameters is a mapping, and §5.2 defines which declaration wins, not what a form shows.

isAdvanced — the idea is accepted, the name can't be. ADR 0007 §1 rules it out twice: "A boolean is an adjective, never is…-prefixed", and "A name says what a value is, not how advanced it is" — which is the clause that retires advanced as a name. That rule is also not merely local taste; Google AIP-140 says booleans should omit the is_ prefix, the Kubernetes API conventions say a boolean property fooable is named Fooable and not IsFooable, and JSON Schema's own annotations are readOnly, writeOnly, deprecated.

placement isn't available either — ADR 0007 spends it on blueprint §4.4's compute pins, and reusing it would recreate the same collision ADR 0007 §3 spends a page resolving for metadata.revision. Proposal is ui.prominence: PRIMARY | SECONDARY, default PRIMARY: it names both states, says what the value is rather than how hard it is, and a third rank stays free later. See the open questions at the end — this one is genuinely arguable.

placeholder → examples, an array of strings. placeholder is an HTML attribute name and describes what a renderer does with the value rather than what the value is; example singular would duplicate a standard JSON Schema annotation at a different arity. examples is that annotation's own name and arity, so nothing new is invented. The prose has to say it is never submitted, unlike default, and that a client ignores it where the value carries an enum.

group is declined, and §7 anticipated the argument while landing on the other side of it. Free text is offered as the smaller commitment; it's the larger one. A group name on a component input is a claim about a form that contains other components' inputs, which the declaring document cannot see — the same line component §6.2 draws for outputs ("An output depends on its own node and nothing else"), and the reason that rule exists. §5.2 merges first-wins across nodes with no way to reconcile "Network" against "Networking", and no author is in a position to fix it because neither document is wrong. order survives the identical objection because a total order can always be produced from what a merged form has; group cannot. Recorded as a gap in §10 rather than shipped — and adding it later is additive and free forever, which is the asymmetry that makes declining cheap and accepting permanent.

§4C — direction accepted, name and shape both change

valueFrom is not available: ComponentOutput.valueFrom is already a DECLARED/DERIVED string enum in the same family. Reusing the word for a discriminated object gives one name two shapes, which is what ADR 0007 §4 exists to prevent.

More substantially — a wholesale value-source union was designed and then rejected, and the reason is worth recording because ADR 0010 §5 gestures at exactly that shape ("Phase 7's value-source union makes that structural rather than a rule to remember"). Collapsing suppliedBy, generator and platformDefault into one four-branch oneOf is very tempting: it makes §6.1's three prose obligations structural and collapses blueprint §5.3's five-condition table to three.

It also makes the corpus's dominant case unrepresentable. n8n.n8nHost and its two siblings carry suppliedBy: USER and platformDefault at once — the platform fills it, the user may override it for a custom domain. All six platformDefault inputs in the catalog are that shape, and it is precisely the sentence §2 wants to be able to say. These are two orthogonal axes, not four members of one: who may type it (USER | CONNECTION) against what fills it when nobody does. oneOf asserts exclusivity — that is what it is for — and the second axis is not a peer of the first. (Two further objections, for the record: tools/src/effective.ts resolves $ref, allOf and the nullable anyOf idiom and reports anything else unresolvable, which ADR 0008 requires of it, and suppliedBy carries a default that is actively resolved today; and ADR 0010 §5's rule is a blueprint rule about a component document, which no shape in either schema can make structural.)

So the narrow version is the right one. suppliedBy stays a two-member enum, generator stays where it is — your line, and it's correct — and platformDefault keeps its name and gains a type discriminator inside it:

platformDefault:
  type: SELF_ADDRESS
  source: PUBLIC_URL
  endpoint: primary

Encoded with x-musher-discriminator beside a oneOf, which is already in component/v1 twice (ComponentEnvVar.value, ComponentWorkload.source), is allowlisted by lint.ts, is rendered by the reference generator, and is the OpenAPI discriminator shape. source and endpoint stay inside the SELF_ADDRESS branch rather than being hoisted — they mean nothing to a future kind. That is also the argument against the nested selfAddress: {…} payload in your example, where the tag and the key would say the same thing twice.

Keeping the name is deliberate: ADR 0005 §2 warns against "a specification that spends a working capability to hold options open for rules nobody has proposed", and platformDefault accurately names all six live uses. What is not deferrable is the tag itself — adding a discriminator later means adding a required field, so it is now or never, which is the same asymmetry ADR 0013 states as "Adding members stays free forever; withdrawing one is free now and never again."

Three things ride along, because they're the same field:

• §6.1's recorded gap gets closed rather than renamed around: "suppliedBy is unconstrained by platformDefault in v1 — a gap, recorded rather than described as a decision." One allOf branch makes the real exclusivity structural (CONNECTION ⇒ neither; generator ⇒ no platformDefault) while leaving USER + platformDefault legal, which is the whole point.
• BlueprintParameter gains the counterpart it lacks, and §5.3's five-condition table row moves with it.
• A live bug §2 half-saw. §5.3's guarantee list — "it declares isRequired: true, or it carries a generator, or its schema declares a default" — has to gain "or it carries a platformDefault" the moment a parameter can carry one, or an authored parameter that does supply the value fails to cover the input it satisfies and ships a false ERR_UNCOVERED_REQUIRED_INPUT.

§2 is right and understates itself

Blueprint §5.1 derives schema, ui and isRequired. The issue notes there is no platformDefault counterpart. generator isn't in that list either — so the section argues at length that a generated input is derived because "three secrets will be generated for you" is worth being able to say, and then does not carry the field that lets a client say it. The property exists on BlueprintParameter; the prose never puts anything in it. That is a separate, non-breaking fix and it should ship on its own.

§6 and §8 — the timing is tighter than the issue thinks

§6 reads the window correctly and misses three things around it.

Release pull requests #1, #2 and #3 are open and have been since 2026-08-08. main-branch.json sets required_approving_review_count: 0 and neither CHANGELOG.md nor the release manifest is a CODEOWNERS path, so any of the three merges on green CI with nobody approving it — and release-tags.json blocks tag deletion, non_fast_forward and update, so the resulting tag is permanent. They need to be drafts, not merely left alone: release-please runs on every push to main and will keep force-pushing and reopening them with the title pinned at 1.0.0 throughout, so they will look identical on the day the work finishes and on the day it started.

There is already an accepted, unimplemented breaking backlog in front of this. ADR 0007, ADR 0009 and ADR 0010 are all Accepted, all dated 2026-08-19, and each carries Relies on: ADR 0005 §1. None is implemented: no resourceType, no componentRef, no metadata.revision, no placement, none of ADR 0007 §4's eight propertyNames grammars, and all 27 of §5's null branches still in place. ADR 0013 is the only one of the four that landed. Every one of them touches this same input contract and needs the same window, so this proposal's breaking half isn't a standalone decision about one field — it's one more item in a pass that already exists and hasn't been run. It will be sequenced with them, which is why the answer here is "yes, and later than you asked".

musher-dev/catalog will go red and stay red. Its suite fetches the bundles from raw.githubusercontent.com/musher-dev/spec/main/… unpinned, on every push, every PR and a daily cron, and the workflow header says that's the point — it's how a spec change that stops accepting an item gets noticed. Exactly right for ordinary changes, and exactly wrong for a multi-PR breaking pass, where it re-reds daily with no catalog activity and its signal stops being distinguishable from a real regression. Something to decide deliberately before the first merge rather than discover the morning after.

§8's reading of the process is otherwise correct: ADR first and on its own, schemas/src/ only, fixtures per behavioural change, traceability regenerated, DCO, scoped commits.

Two questions back to you

Both are close calls and the thread is a better place to settle them than a maintainer's judgement alone.

1. ui.prominence: PRIMARY | SECONDARY, or a boolean? AIP-126 permits a boolean "where it is clear that no further flexibility will be needed, and the default value must be false", which is arguably this. The enum is proposed because a third rank (hidden, say) is plausible and free later, and because a noun naming the axis dodges ADR 0007's objection more cleanly than any adjective on offer. Worth also naming the honest weakness: prominence is the only one of these additions with no semantic counterpart, and your own motivating example — n8n's three URL overrides — is derivable from "carries a platformDefault". The reason to declare it anyway is that deriving it would be a heuristic, and §6.4 exists to stop the derivation being one.

2. Is group declined or deferred? The argument above is for declining, but it rests on a claim about merged multi-node forms that the thirteen-item corpus can't yet test — every blueprint there derives, and none has enough fields for grouping to have been felt. If someone has an item where the wall is real, that's worth more than the argument.

Everything else is settled enough to write.